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Preface 


The  purpose  of  this  study  was  to  make  an  assessment  of  the 
suitability  of  Integrated  Services  Digital  Network  (ISDN)  technology  for 
meeting  the  Royal  Australian  Air  Force  (RAAF)  Information  Systems  (IS) 
goal  architecture.  The  report  contains  some  technical  information  on 
network  protocols,  so  if  you  do  not  have  a  good  understanding  of 
networking  you  may  wish  to  consult  the  network  primer  at  Appendix  A. 

The  lack  of  specific  data  on  future  network  load  requirements 
forced  me  to  resort  to  a  concept  of  a  standard  work  unit  (SWU)  to  gain 
some  appreciation  of  the  transfer  capability  of  the  basic  ISDN  channel. 
This  reduced  the  strength  of  the  conclusions  that  could  be  drawn  from 
the  analysis  of  network  performance. 

In  performing  the  analysis  of  requirements  and  investigating 
alternative  solutions  I  received  help  from  a  number  of  people.  I  would 
like  to  thank  my  thesis  advisor,  Capt  Bruce  L.  George,  Ph.D.,  for  his 
support  and  guidance  in  completing  this  task.  He  was  particularly 
helpful  in  recommending  the  use  of  computer  simulation  to  support  the 
findings.  SQNLDR  Bill  Ely  from  DIS-AF  kept  me  informed  on  the  changing 
computing  environment  in  the  RAAF  and  I  would  like  to  thank  him  for 
that.  I  also  wish  to  thank  Capt  David  X.  Brabender  from  the  USAF  Model 
Base  Program  for  sharing  ideas  of  base  communications  requirements 
during  my  visit  to  Mather  AFB,  CA.  Finally,  I  would  like  to  t.iank  my 
wife  Carol  for  her  patience  and  understanding  during  this  epic  event. 


Richard  M.  Halley 
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The  purpose  of  this  -study' was  to  define  an  information  systems 
goal  architecture  for  the  Royal  Australian  Air  Force  that  uses 
Integrated  Services  Digital  Network  (ISDN)  as  the  basic  network 
structure.  To  do  this  required  gathering  information  from  previous 
studies  on  architecture  requirements  and  present  related  projects. 
Important  requirements  were  identified  as  the  ability  to  exchange  data 
between  the  various  systems,  the  requirement  to  protect  classified  data 
and  the  requirement  to  support  deployed  RAAF  operations. 

An  important  Australian  Defence  project  is  the  Defence  EDP  Systems 
Integrated  Network  Environment  (DESINE)  that  is  intended  to  achieve 
interoperability  among  the  various  information  systems.  DESINE  details 
are  not  firm,  but  early  indications  are  that  proprietary  IBX  network 
protocols  will  be  used  with  a  strong  emphasis  on  mainframe  computing. 
This  concept  is  contrary  to  the  current  industry  trends  where  the  use  of 
smaller  microcomputer  based  systems  that  use  open  systems  architectures 
is  advocated.  The  architecture  presented  in  this  report  is  offered  as 
an  alternative  to  DESINE. 

Analysis  of  the  options  for  using  ISDN  technology  indicated  that 
the  concept  of  frame  relay  is  ideally  suited  to  the  RAAF  requirements. 
Frame  relay  is  a  form  of  packet  switching, -\within  an  ISDN,  where  high 


throughput  and  low  delay  are  achieved  by  reducing  the  processing 
required  per  packet.  A  migration  path  usihg  conventional  X.25  packet 


switching  is  proposed. 


\ 


The  proposed  architecture  distributes  processing  power  to  user 
locations  to  reduce  the  network  traffic.  This  setup  was  simulated  using 
the  CACI  COXNET  II. 5  program  and  used  a  surrogate  load  measure  based  on 
a  standard  work  unit.  This  was  necessary  because  of  the  unavailability 
of  projected  network  load  data.  The  results  indicated  that  with 
distributed  processing  ISDN  can  meet  all  the  requirements  of  the  RAAF 
goal  architecture. 
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USING  INTEGRATED  SERVICES  DIGITAL  NETWORK  TECHNOLOGY 
AS  THE  BASIS  FOR  THE  ROYAL  AUSTRALIAN  AIR  FORCE 
INFORMATION  SYSTEMS  GOAL  ARCHITECTURE 


I .  Introduction 


General  Issue 

In  October  1986,  the  Royal  Australian  Air  Force  (RAAF)  Computing 
Systems  Policy  Committee  endorsed  a  paper  titled  "RAAF  ADP  Development 
Plan."  This  plan  advocates  the  development  of  information  systems  (IS) 
along  the  vertical  lines  of  the  four  functional  elements  of  operations, 
administration,  supply,  and  maintenance.  A  subsequent  draft  paper 
titled  "A  Development  Framework  for  RAAF  Information  Systems"  stressed 
the  importance  of  a  unifying  total  system  concept ,  the  transfer  of  data 
between  the  functional  element  systems ,  and  the  requirement  to  protect 
classified  data  (33).  This  second  paper  is  discussed  in  Chapter  II. 
There  are  two  defence-wide  projects  that  are  designed  to  simplify  the 
integration  of  IS  within  the  three  Services  and  Defence  Central  and  to 
provide  interoperability  between  the  various  agencies. 

The  first  project  is  the  Defence  Integrated  Secure  Communications 
Network  (DISCON),  which  will  provide  a  strategic,  operational  and  day- 
•  to-day  communications  capability.  Initial  services,  which  are  just 

starting  to  become  available,  include  secure  voice,  facsimile,  message 
switching  and  dedicated  data  circuits.  The  network  is  being  expanded  to 
include  classified  and  unclassified  data  packet  switching  services. 

This  expansion  will  provide  the  wide  area  network  (WAN)  capability  to 
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allow  the  transfer  of  data  between  IS  at  the  various  defence 
establishments . 

The  other  major  project  is  also  concerned  with  providing  a 
standardized  networking  capability.  The  Defence  EDP  Systems  Integrated 
Network  Environment  (DESINE)  will  allow  the  inter-networking  of  various 
computer  systems  in  a  consistent  way.  The  concept  of  DESINE  is  to  allow 
the  decentralization  on  IS  by  providing  a  standard  network  architecture 
for  the  interoperation  of  distributed  computer  systems.  The  DESINE 
standards  are  to  be  used  for  all  defence  IS  computing  requirements, 
unless  an  exemption  is  obtained  (10). 

The  DESINE  contract  has  been  awarded  to  IBM  Australia  Ltd  and  is 
effective  from  1989  to  1994.  Because  of  the  recency  of  this  award  there 
is  still  some  confusion  as  to  what  products  will  be  made  available  under 
DESINE.  Early  indications  are  that  IBX's  proprietary  System  Network 
Architecture  (SNA)  will  be  used  with  an  emphasis  on  mainframe  based 
solutions  (19).  At  least  four  different  levels  of  computing  will  be 
provided,  ranging  from  the  IBX  3090  mainframe  to  an  IBX  PC,  with  each 
level  using  a  different  operating  system.  Xany  RAAF  IS  project  managers 
have  found  it  difficult  to  match  a  DESINE  based  solution  to  their  user 
requirements  (14). 

In  defining  the  requirements  for  DESINE,  the  IS  policy  makers 
recognized  that  there  may  be  circumstances  where  DESINE  based  solutions 
may  not  be  appropriate.  This  may  include  embedded  systems,  specialist 
systems  that  have  security  concerns,  urgent  operational  requirements, 
and  unsuitable  contract  solutions.  Solutions  could  be  unsuitable 
because  of  function,  time  required  to  implement,  or  project  costs  where 
project  costs  includes  all  aspects  of  the  introduction  of  the  system 
(11:3). 
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The  use  of  DISCON  to  provide  the  WAN  capability  will  be  an 
important  component  of  the  IS  development  strategy,  but  equally 
important  is  the  development  of  a  unifying  total  system  concept  that 
»  meets  the  management  and  operational  needs  of  the  RAAF.  IS  in  the  RAAF 

involve  more  that  just  support  for  the  four  functional  elements.  Future 
systems  will  include  office  automation  (OA),  management  information 
systems  (XIS)  and  decision  support  systems  (DSS)  to  support  the 
activities  of  middle  and  upper  level  management.  These  XIS  and  DSS  will 
use  the  corporate  data  provided  by  the  functional  systems,  and  may  cross 
functional  boundaries.  An  example  of  this  would  be  mission  planning 
that  requires  weapon  and  POL  availability,  aircraft  and  aircrew 
availability,  and  accommodation  requirements  at  another  base. 

The  area  that  is  concerned  with  the  management  of  these  decision 
aiding  tools,  and  the  information  they  process,  is  referred  to  as 
information  resource  management  (IRX).  IRX  has  the  concept  that 
information  is  an  organizational  resource  and  requires  top  level 
attention  to  ensure  it  is  managed  correctly.  The  IRX  function  is 
involved  with  traditional  data  processing  applications, 
teleconmunciations  and  OA  and  is  an  attempt  to  provide  a  coordinated 
approach  to  the  management  of  IS  (8:632-633). 

Specific  Problem 

The  concept  of  operations  of  the  RAAF  requires  the  support  for 
deployed  operations  that  may  be  from  non-operational  RAAF  bases, 
unmanned  RAAF  bases,  and  possibly  civilian  airfields.  The  IS  that  are 
developed  to  support  the  four  functional  elements  must  take  these 
deployed  operations  into  account.  This  research  will  determine  a  RAAF 
IS  goal  architecture  based  on  Integrated  Services  Digital  Network  (ISDN) 
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technology,  that  uses  DISCON  to  provide  the  WAN  component,  and  although 
not  specifically  based  on  DESINE  products,  will  meet  the  DESINE  goals. 

Definition  of  ISDN.  Integrated  Services  Digital  Network  (ISDN)  is 
defined  by  the  Consultative  Committee  of  International  Telephony  and 
Telegraph  (CCITT)  as  an  access  method  where  a  small  number  of 
standardized  interfaces  are  used  to  provide  a  single  access-point  to  an 
end-to-end  digital  network  providing  voice,  video,  circuit  switched  data 
and  packet  switched  data  services  (38). 

Research  Objectives 

The  following  steps  are  required  to  determine  the  IS  goal 
architecture : 

1.  identify  RAAF  IS  requirements  sufficient  to  allow  network 
service  and  capacity  planning; 

2.  determine  any  computer  industry  trends  that  are  applicable 
to  RAAF  IS  development; 

3.  identify  the  goals  of  the  DESINE  project; 

4.  identify  DISCON  interfacing  specifications  and  associated 
network  protocols; 

5.  determine  how  ISDN  technology  can  be  used  to  facilitate  base 
level  communications; 

6.  design  the  goal  architecture  based  on  the  information 
obtained  above;  and 

7.  evaluate  the  goal  architecture  using  simulation  to  assess 
network  performance. 
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Scope  of  the  Research 

There  are  several  existing  IS  in  use  in  the  RAAF  today  and  each  of 
the  four  functional  elements  has  identified  requirements  for  new  or 
replacement  IS  in  the  near  future.  This  research  will  not  look  at  any 
requirements  of  the  existing  functional  systems,  but  instead  will  define 
an  architecture  for  the  integration  of  the  new  systems.  Additionally, 
the  research  will  concentrate  on  establishing  a  base  level  architecture. 
The  RAAF  goal  architecture  would  consist  of  a  hierarchy  of  appropriately 
sized  network  configurations  at  all  bases,  depots,  headquarters  and  Air 
Force  Office. 

Background 

Chapter  II  provides  some  detailed  background  on  topics  that  are 
relevant  to  the  selection  of  the  goal  architecture.  First  a  more 
detailed  look  at  the  paper  titled  "A  Development  Framework  for  RAAF 
Information  Systems"  gives  some  guidance  on  the  problems  that  must  be 
solved.  Current  RAAF  IS  policy  and  any  existing  projects  that  may 
relate  to  this  research  are  discussed  and  an  assessment  made  of  the 
level  of  maturity  of  the  development  of  IS  in  the  RAAF.  Then  the  ISDN 
concept  is  explained  in  general  terms  and  more  specifically  how  the 
military  can  benefit  from  ISDN  technology.  Finally  a  look  at  how  the  US 
Xilitary  is  planning  to  use  ISDN  technology  for  local  information 
transfer  and  to  provide  world-wide  interoperability. 


5 


II .  Background 

A  Development  Framework  for  RAAF  Information  Systems 

The  concept  for  the  development  of  information  systems  in  the  RAAF  • 

is  along  the  vertical  lines  of  the  four  functional  areas  of  operations, 
administration,  supply  and  maintenance.  A  hierarchy  of  automatic  data 
processing  (ADP)  sites  is  to  be  established  at  RAAF  bases,  supply  and 
maintenance  depots,  Air  Headquarters,  Support  Command,  and  Air  Force 
Office.  Components  of  the  information  systems  for  each  functional 
element  would  be  housed  in  these  ADP  sites.  At  each  node  in  the 
hierarchy  some  form  of  local  area  network  (LAX)  would  be  used  to  provide 
user  access  to  the  information  systems  (33:1-2). 

Support  for  Deployments .  At  the  base  level  the  functional 
elements  are  overlaid  by  the  particular  operational  role  of  that  base. 

While  an  operational  role  is  concentrated  at  a  'home'  base,  the  concept 
of  operations  requires  support  for  deployed  forces  at  any  other 
operational  or  non-operational  base.  The  development  of  information 
systems  must  take  these  deployed  operations  into  account  (33:2).  Two 
other  important  considerations  in  the  development  of  information  systems 
are  interoperability  and  security. 

Interoperability .  Each  functional  element  will  have  private  data 
and  data  that  is  required  to  be  shared  with  the  other  elements. 

Interoperability  is  concerned  with  the  management  and  control  of  this 
shared  data.  Having  defined  inter-networking  standards  will  greatly 
assist  data  interoperability  but  some  method  for  standardized  data 

•* 

interchange  must  be  provided  (33:4). 

Security.  The  information  that  will  be  stored  on  general  purpose 
information  systems  can  be  divided  into  two  security  levels; 
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Unclassified-Restricted  and  Confidential-Secret.  Additionally,  data  may 
be  classified  on  a  need-to-know  basis.  The  development  framework 
proposes  the  installation  of  separate  LANs  to  service  users  at  the  two 
security  levels.  Operations  staff  would  primarily  operate  on  the  higher 
level  LAN,  while  the  other  elements  would  use  the  lower  level  system.  A 
one-way  link  from  the  lower  level  to  the  higher  level  system  must  be 
provided.  Additionally,  some  information  from  the  Confidential-Secret 
level  must  be  made  available  to  selected  users  outside  of  operations 
that  have  the  need-to-know  and  appropriate  security  clearances  (33:6). 

RAAF  IS  Policy  and  Existing  Projects 

To  meet  the  demand  for  general  computing  services  the  RAAF 
Computing  Services  Policy  Committee  endorsed  the  policy  in  October  1986 
that  stated,  wherever  possible,  user  computing  support  requirements 
should  be  provided  by  Unix  based  multi-user  minicomputers.  This 
decision  resulted  in  the  acquisition  of  about  80  small  to  medium  size 
multi-user  computers  for  use  in  all  functional  areas.  These  systems  are 
using  the  Uniplex  II  Plus  integrated  office  system  and  the  Informix 
database  management  system  (7:13). 

To  continue  the  work  started  with  the  paper  discussing  the 
development  framework  for  RAAF  IS,  a  project  called  RAAF  On-base  Data 
Communications  Network  (RODNET)  was  initiated  to  progress  the 
development  of  a  high  capacity  LAN  infrastructure.  The  current  status 
of  RODNET  is  unknown,  but  believed  to  be  at  a  very  early  stage  of 
requirements  definition.  The  goals  of  RODNET  and  of  this  research  are 
much  the  same  and  this  should  at  least  provide  two  different  approaches 
to  solving  base-level  communications  requirements. 
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RAAF  Information  Systems  Xaturif 


The  Nolan  six  stage  model  is  a  useful  conceptual  tool  to  help 
understand  the  level  of  maturity  that  information  systems  have  reached 
in  an  organization.  The  model  consists  of  six  necessary  stages  of 
growth  toward  maturity.  The  six  stages  are  initiation,  uncontrolled 
expansion,  control  and  planning,  integration  of  applications,  data 
administration  activity,  and  maturity  where  applications  are  complete 
and  match  the  organizational  objectives  (8:450-453). 

The  introduction  of  the  Unix  based  general  purpose  computing 
systems  provided  the  first  wide-spread  use  of  computers  in  the  RAAF 
outside  the  data  processing  areas.  Because  of  the  difficulty  in 
computer  acquisition,  many  agencies  applied  the  'back  door*  approach  to 
acquire  computing  support,  mainly  in  the  form  of  PCs.  This  led  to  a 
non-standard  approach  to  solving  IS  problems.  In  1987,  Air  Force  Office 
became  aware  that  the  management  of  RAAF  computing  resources  and  future 
requirements  was  a  formidable  task.  To  tackle  this  task,  the 
Directorate  of  Information  Systems  -  Air  Force  (DIS-AF)  was  formed  to 
replace  the  directorate  previously  responsible  for  such  matters.  Among 
other  responsibilities,  DIS-AF  would  determine  and  promulgate  policy  and 
procedures  for  the  development  of  computing  within  the  RAAF  (7:13). 

The  RAAF  has  recognized,  but  not  yet  solved,  the  problems 
associated  with  the  introduction  and  management  of  IS.  This  would  seem 
to  place  the  RAAF  at  the  Nolan  control  and  planning  phase. 


The  ISDN  Concept 

The  Need  for  Integration.  A  telephone  network  consists  of  a  large 
number  of  telephones  and  a  series  of  interconnected  switching  centers  or 
exchanges.  Early  networks  used  only  analog  techniques  where  voice 
information  is  transmitted  by  modulating  voltage  signals  on  the 
telephone  line.  By  the  1970s,  the  telephone  network  providers  had 
realized  the  reliability  and  economic  advantages  of  using  digital 
switching  of  information  between  the  exchanges  (15:332).  To  utilize 
digital  switching  a  voice  signal  must  be  converted  to  a  digital  format 
where  a  pattern  of  binary  zeros  and  ones  is  used  to  represent  the  voice 
pattern.  The  widespread  use  of  digital  computers  in  the  business  world 
has  led  to  the  development  of  dedicated  data  networks.  These  data 
networks  are  usually  operated  by  the  telephone  companies  (15:333).  The 
phased  development  of  the  telephone  and  data  networks  in  different 
countries  has  led  to  minor  differences  in  implementation  standards 
(32:835).  These  differences  affect  the  ability  to  provide  efficient, 
world-wide  communications.  If  the  voice  and  data  networks  can  be 
integrated  into  a  combined  digital  network  there  would  be  an  improvement 
in  network  services  and  significant  savings  in  maintenance  costs 
(15:333).  Integrated  Services  Digital  Network  (ISDN)  is  the  only 
technology  being  considered  to  provide  this  integration  (32:833). 

ISDN  Interface  Standards.  The  ISDN  standards  specify  separate 
data  and  network  signalling  channels.  The  data  (B)  channels  are  64  kbps 
(kilo,  meaning  thousands,  bits  per  second)  and  an  ISDN  interface  can 
have  from  two  to  30  such  channels.  A  Basic  Rate  Interface  (BRI)  has  two 
B  channels  and  in  Australia  the  Primary  Rate  Interface  (PRI)  has  30  B 
channels.  Each  interface  has  a  separate  (D)  channel  for  network 
signalling  and  control  (30:762).  All  channels  are  multiplexed,  or 
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combined,  so  they  can  be  transmitted  over  the  existing  telephone  wiring 
between  the  exchange  and  the  ISDN'  access  point.  This  provides  access  to 
data  as  well  as  voice  services  from  any  telephone  connection  in  an  ISDN 
(30:762). 

Existing  Data  Networks.  An  implementation  plan  for  an  ISDN  must 
allow  for  integration  of  existing  terminal  equipment  and  data  networks. 
ISDN  adapters  will  be  available  for  most  of  the  existing  hardware  and 
the  standards  provide  for  initial  access  to  existing  data  networks  from 
the  ISDN  interface  (32:837).  The  amount  of  money  invested  in  these  data 
networks  will  to  a  large  extent  determine  when  all  services  are 
converted  to  ISDN  (15:336).  The  most  common  type  of  data  network  is  the 
X.25  packet  switching  network  and  ISDN  standards  provide  two  ways  to 
interface  to  these  networks.  The  first  is  to  use  the  unused  capacity  of 
the  D  signalling  channel  to  transfer  packet  data.  The  second  method  is 
to  use  the  signalling  channel  to  establish  a  circuit  switched  connection 
to  a  packet  switching  node  over  a  B  data  channel  (38:277). 

Developments  in  Video  Transmission.  To  transmit  a  full  motion 
video  signal  in  a  digital  format  requires  about  80  Mbps  of  bandwidth. 
Until  B-ISDN  is  widely  available,  this  high  bandwidth  requirement  will 
limit  the  distribution  of  normal  TV  video  using  normal  ISDN 
capabilities.  However,  one  area  where  video  is  becoming  increasingly 
important  is  in  teleconferencing.  Considerable  bandwidth  can  be  saved 
by  only  transmitting  the  changes  necessary  to  reconstruct  the  video 
picture,  instead  of  the  whole  video  frame  many  times  per  second.  Good 
quality  video,  suitable  for  teleconferencing,  can  be  transmitted  in  as 
little  as  384  kbps.  With  reductions  in  quality,  for  security 
surveilance  for  example,  the  bandwidth  can  be  reduced  even  further.  The 
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decision  to  use  384  kbps  was  made  because  that  was  a  standard  channel 
available  in  ISDN  (21:30). 

Future  ISDN  Developments 

Enhanced  Packet~mode  Techniques .  Xost  existing  data  networks  use 
a  packet  switching  technique  to  maximize  network  utilization.  The 
network  switching  nodes  divides  the  data  into  small  packets  for  routing 
through  the  network.  Xore  efficient  packet-mode  techniques  are  being 
planned  for  ISDN  and  B-ISDN  that  will  allow  the  complete  replacement  of 
the  existing  networks  (16:345).  Using  packet  switching  within  a  single 
B  data  channel  would  allow  up  to  16  terminals  to  effectively  share  the 
same  ISDN  interface  (30:763).  Enhanced  packet-mode  techniques  will  also 
be  the  basis  of  LAN  inter-connection  using  ISDN  (6). 

Broadband  ISDN.  To  satisfy  much  higher  data  transfer 
requirements,  the  CCITT  is  processing  recommendations  for  the 
specification  of  a  Broadband  ISDN  (B-ISDN).  This  new  technology  will 
use  fiber  optics  and  be  capable  of  data  rates  of  150  mbps  (million  bps) 
(16:343).  This  will  allow  the  distribution  of  high  quality,  full 
bandwidth  video.  The  price  of  B-ISDN  is  likely  to  be  similar  to  cable 
TV  and  this  widespread  availability  of  cheap,  high  capacity  data 
services  should  be  useful  to  the  military  (35:778). 

Xilitarv  Use  of  ISDN 

ISDN  techniques  provide  solutions  to  most  of  the  conmuni cat ions 
problems  that  the  military  have  faced  in  the  past.  These  include  poor 
utilization  of  data  circuits,  incompatibility  between  various  hardware 
vendors,  and  slow  provisioning  times  (29:50.5.2).  Xost  industrialized 
countries,  including  NATO  members  and  other  allies,  are  committed  to 
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implementing  ISDN  (35:778).  A  64  kbps  channel  can  provide  high  quality 
voice  or  be  used  to  transport  computer  or  other  data.  As  many  existing 
military  users  are  transmitting  data  at  9.6  kbps  or  less,  a  lot  of 

military  communications  requirements  can  be  met  by  the  standard  64  kbps  t 

B  data  channel.  If  required,  the  data  channels  can  be  combined  to  give 
higher  transfer  rates  (32:833).  Soon  the  most  common  telecommunications 
interface  to  be  found  around  the  world  will  be  an  ISDN  connection  and 
the  military  should  not  miss  out  on  this  opportunity  for  global 
connectivity  (32:835). 

The  common  network  signalling  and  control  channel  provides  much  of 
the  flexibility  in  the  ISDN.  As  well  as  providing  normal  call  set-up 
and  monitoring,  like  identifying  a  pending  caller  when  phone  is  in  use, 
specific  user-to-user  signalling  protocols  can  be  developed.  These 
additions  are  allowed  for  in  the  ISDN  specifications  (32:835). 

Commercial  ISDN  implementations  would  meet  most  of  the  military's 
requirements,  but  areas  of  access  control,  preemption,  network 
management,  and  encryption  must  be  further  examined. 

Access  Control.  ISDN  calling  procedures  can  improve  access 
control  by  passing  the  caller's  number  when  a  call  is  established. 

Additional  information  such  as  user-ID  can  also  be  passed.  This 
signalling  protocol  can  be  used  to  grant  or  deny  access  to  any  telephone 
number  and  user-ID  combination  (30:766).  The  standards  committees  have 
discussed  increasing  the  access  control  capability  of  ISDN  but  more 
detailed  study  is  still  required  (32:836).  According  to  Nercer  and 
Edwards  the  onus  is  on  the  military  to  identify  any  special  requirements 
to  ensure  they  can  be  implemented  in  a  consistent  manner  (29:50.5.1). 

Preemption  Capability.  Xilitary  communications  must  ensure  that 
essential  C^I  and  other  high  precedence  traffic  is  not  blocked  in  a  busy 
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network.  Existing  military  networks  provide  a  multi-level  precedence 
and  preemption  (MLPP)  capability  to  prevent  blocking,  and  recently  the 
Defense  Communications  Agency  submitted  XLPP  requirements  to  the 
standards  committees  (32:836).  The  military  will  have  to  pay  for  this 
capability  to  be  built  into  military  ISDN  switches  as  preemption  on 
public  networks  is  not  permitted  (24:722). 

Network  Management .  The  flexible  common  signalling  channel  in  the 
ISDN  interface  improves  the  network  management  and  maintenance 
capabilities  (35:777).  The  customer  has  more  control  over  an  ISDN  and 
can  initiate  reconfiguration  during  periods  of  degraded  operation.  The 
rapid  switching  capability  of  an  ISDN  allows  virtual  private  networks  to 
be  established  and  disbanded  on  demand  within  seconds.  This  improves 
network  availability  by  allowing  the  switching  exchanges  to  route 
traffic  around  any  faulty  paths  (30:568).  This  is  the  type  of  flexible 
network  management  required  in  a  military  network  (29:50.5.3). 

Encryption.  The  separation  of  network  signalling  from  data 
simplifies  the  use  of  encryption  devices  in  an  ISDN  and  allows  military 
users  to  pass  encrypted,  sensitive  data  over  public  networks  (35:766). 
This  is  possible  because  the  connection  is  made  using  the  D  signalling 
channel  and  data  passed  on  the  encrypted  B  channel.  Some  of  the  current 
encryption  devices  may  not  be  compatible  with  ISDN  and  will  therefore 
need  replacing  (32:837). 

US  Military  ISDN  Plans 

The  US  Army,  Navy,  and  Air  Force  have  all  included  ISDN  technology 
as  part  of  the  solution  to  providing  for  the  local  transfer  of 
information  in  the  post-1995  time  frame.  Each  Service  has  taken  a 
different  approach  and  each  will  be  discussed  briefly  below. 
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Army.  The  Army  considers  that  most  users  can  be  serviced  by  the 
2B  +  D  BRI  and  intends  to  replace  most  of  its  20,000  LANs  with  this 
service.  Achieving  full  ISDN  capability  will  take  a  long  time  as  only 
about  eight  of  the  400  total  switches  are  being  upgraded  to  an  ISDN  #■ 

capability  each  year  (2:362). 

Navy.  Of  the  three  Services  the  Navy  tends  to  rely  less  on  fixed 
shore-based  communications  facilities.  At  the  base  level  the  main  ISDN 
switch  will  be  connected  to  smaller  ISDN  and  non-ISDN  switches.  The 
Navy  sees  ISDN  technology  as  a  means  of  connectivity  between  LANs  rather 
than  a  replacement  for  the  LANs  themselves  (2:366). 

Air  Force.  The  Air  Force  intends  to  use  ISDN  to  provide  world¬ 
wide  interoperability  between  its  bases  (2:366).  The  Air  Force  has  the 
most  advanced  plans  for  the  introduction  of  ISDN  services.  The  local 
information  transfer  architecture  (LITA)  consists  of  multiple  ISDN 
switches  connected  via  high-capacity  fiber  optics.  Again  most  users 
will  be  provided  with  the  2B  +  D  BRI  (13 .'page  3-1). 

Comments  and  Conclusions 

The  formation  of  DIS-AF  is  an  important  step  in  progressing  the 
state  of  RAAF  IS  towards  maturity,  although  a  lot  of  work  lies  ahead. 

The  development  framework  for  RAAF  information  systems  has  indicated 
that  the  three  main  areas  for  concern  are  the  support  for  deployed 
operations;  interoperability  between  the  operations,  administration, 
supply,  and  maintenance  systems;  and  protecting  classified  information 
but  still  making  it  available  to  authorized  users.  A  key  component  of 
the  goal  architecture  is  the  LAN  and  it  appears  that  ISDN  is  a  suitable 
candidate . 
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The  conversion  of  the  public  telephone  networks  to  an  ISDN  will 
result  in  increased  functionality  at  lower  costs.  An  ISDN  is  capable  of 
combining  all  voice  and  data  requirements  into  one  network.  The 
separation  of  the  network  signalling  from  the  data  provides  much  of  the 
flexibility  of  the  ISDN.  All  industrialized  nations  are  planning  for 
ISDN,  and  this  is  the  only  technology  being  considered  for  the  future. 

While  many  military  needs  could  be  met  by  standard  conmercial  ISDN 
implementations,  there  are  some  unique  military  requirements  that  must 
be  factored  into  the  ISDN  development  process.  These  requirements  are 
for  better  access  control  and  network  management  capabilities,  a 
preemption  capability,  advanced  conferencing  facilities  and  the  use  of 
encryption  equipment  on  public  networks. 

Initial  implementations  can  use  existing  terminal  equipment  and 
X.25  packet  switching  data  networks  until  they  can  be  cost-effectively 
replaced.  The  planned  developments  of  the  enhanced  packet-mode 
capability,  and  of  B-ISDN,  further  support  that  this  is  the  type  of 
technology  that  the  military  should  be  adopting  and  encouraging. 

In  the  US,  all  three  Services  have  included  ISDN  in  their  local 
information  transfer  architectures.  The  flexibility  of  ISDN  seems  to 
meet  the  military's  communications  requirements  using  mainly  standard 
commercial  implementations.  For  the  same  reasons,  this  is  the  type  of 
technology  that  should  be  considered  for  the  RAAF  information  systems 
goal  architecture. 
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Ill .  Xethodoloev 

The  methodology  used  to  determine  the  architecture  was  based  on 
authoritative  opinion  with  simulation  used  to  evaluate  the  solution. 
The  steps  followed  to  satisfy  the  research  objectives  are  described 
below. 


Research  Obiectives  Steps 

IS  Requirements.  A  letter  was  sent  to  DIS-AF  requesting 
information  on  the  types  of  services  and  estimated  traffic  volume  for 
the  new  functional  element  information  systems  and  any  other  known 
requirements . 

Computer  Industry  Trends.  A  review  of  current  literature  was 
conducted  to  establish  what  current  industry  trends  were  applicable  to 
the'RAAF  IS  goal  architecture. 

DESINE  Goals.  The  same  letter  to  DIS-AF  also  requested  details  of 
the  DESINE  contract,  in  particular  available  computers,  operating 
systems  and  network  protocols . 

DISCON  Specifications.  The  Australian  Department  of  Defence  - 
Project  Development  and  Communications  Division  was  contacted  to  obtain 
the  latest  information  on  DISCON  packet  switching  interfacing 
requirements . 

Options  for  Using  ISDN  Technology.  A  literature  review  was  used 
to  determine  the  latest  ISDN  standardization  efforts  and  what  future 
developments  are  likely.  The  USAF  Local  Information  Transfer 
Architecture  (LITA)  was  examined  and  several  aspects  of  the  LITA,  that 
were  relevant  to  the  RAAF  goal  architecture,  were  discussed  with  the 


Xodel  Base  Program  staff  at  Xather  APB,  Sacramento  CA,  during  a  four  day 
visit  in  June  1989. 

Design  Architecture.  Using  the  information  derived  from  above, 
and  considering  the  requirements  for  cross-domain  access  to  corporate 
information,  the  security  aspects,  and  the  support  necessary  for 
deployments ,  a  goal  architecture  was  defined. 

Evaluate  Architecture.  The  goal  architecture  was  simulated  using 
the  CACI  COyyNET  II. 5  communications  simulation  package  to  determine  the 
throughput  and  delay  parameters  of  the  proposed  solution. 
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IV.  Findings 


IS  Requirements 

The  four  functional  elements  are  at  various  stages  in  defining  the 
requirements  for  specific  IS.  A  recent  major  reorganization  of  Air 
Force  Office,  and  much  debate  over  the  virtues  of  centralized  verses 
distributed  database  storage,  has  made  it  nearly  impossible  to  define  IS 
requirements  sufficient  to  allow  a  network  architecture  to  be  defined. 

An  assumption  has  been  made  that  user  terminals  will  range  from 
relatively  'dumb'  devices  for  transaction  processing,  to  high 
performance  workstations  for  command  and  control  or  DSS  requirements. 
Another  assumption  is  that  there  is  at  least  a  requirement  to  have  local 
database  storage  for  some  information.  As  the  storage  of  data  is  likely 
to  change  in  the  future,  as  technology  allows  for  truly  distributed 
databases ,  the  goal  architecture  should  be  independent  of  data  storage 
requirements . 

The  reply  received  from  DIS-AF  concerning  the  new  functional 
element  projects  had  some  data  associated  with  network  loadings,  but 
unfortunately  the  information  was  too  general  to  be  useful  as  input  for 
the  computer  simulation  model  (14).  Information  is  required  on  the  type 
and  nature  of  expected  traffic,  like  the  frequency  of  a  particular  event 
and  the  amount  of  network  data  transfer  generated  by  that  event.  As  the 
information  systems  for  the  functional  elements  are  in  the  early  project 
stages,  this  type  of  information  is  just  not  available.  Because  the 
simulation  of  the  proposed  goal  architecture  is  an  important  part  of 
this  research,  some  other  method  of  providing  the  network  load  was 
required . 
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The  method  adopted  was  to  define  a  standard  work  unit  (SWU)  as  a 


number  of  separate  activities  completed  within  a  five  minute  period. 

The  activities  consisted  of  a  database  query  session,  where  several 
queries  are  made  separated  by  simulated  user  thinking  time,  and  a  two- 
way  exchange  of  messages  or  files.  The  details  of  the  SWU  are  contained 
in  Appendix  B. 

By  defining  the  SWU  it  was  possible  to  vary  the  load  applied  to 
the  proposed  network  to  see  the  effect  on  the  throughput  and  delay 
performance  parameters.  These  parameters  are  discussed  below  in  the 
architecture  validation  section. 


Computer  Industry  Trends 

Network  requirements  are  very  much  determined  by  the  number  and 
location  of  computers  and  terminals/workstations  on  a  typical  base.  For 
this  reason  an  assessment  of  the  likely  computer  configuration  was 
necessary.  The  following  quote  provides  much  insight  into  the  nature  of 
the  computer  configuration: 

Each  of  the  four  fundamental  elements  will  be  supported  by  a 
discrete  Information  System  that  has  sub-elements  distributed 
across  the  WAN.  Interoperability  between  these  discrete  systems 
is  provided  by  connectivity  through  common  networks,  and  by  the 
application  of  common  representation  of  shared  data.  The 
architecture  of  each  functional  system  will  be  unique,  though 
resources  could  be  shared  if  practicable.  Processing  power  will 
be  distributed  as  necessary  to  match  the  demands  of  local 
processing  requirements,  communications  requirements,  and  the 
economies  of  central  data  management.  Applications  would  be 
distributed  as  close  to  the  end-user  as  practicable,  with 
appropriate  central  configuration  management.  Local  data  would  be 
managed  at  the  ADP  Centre.  (33:10) 

Distributed  Computing.  One  of  the  aims  of  DESINE  is  to  provide 
effective  vertical  and  lateral  interaction  between  the  distributed 
computer  systems  that  comprise  the  functional  elements  (10:A-1). 

Activity  in  the  computer  industry  in  general  seems  to  support  the 
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concept  of  distributed  computing.  Downsizing  is  a  term  that  is  used  to 
describe  designing  new  systems  to  operate  on  departmental  minicomputers 
or  networked  PCs  (17:15).  Much  of  this  movement  is  because  of  the 
increased  performance  and  reduced  costs  of  microprocessor  based  systems. 
The  introduction  of  widely  distributed  computer  systems  requires  some 
changes  in  the  way  application  programs  are  development. 

Centralized  Computing.  Earlier  concepts  of  computer  architecture 
consisted  of  terminals,  usually  connected  to  some  form  of  concentrator, 
that  would  establish  an  interactive  session  with  a  host  computer.  Many 
of  these  terminals  were  character  based  where  a  character  entered  on  the 
terminal  would  be  sent  to  the  computer.  The  computer,  or  at  least  a 
front-end  communications  processor,  would  echo  the  character  back  to  the 
terminal.  If  a  single  character  were  to  be  sent  using  a  layered  network 
protocol,  where  each  protocol  layer  adds  more  control  information,  the 
effective  throughput  would  only  be  a  few  percent.  Many  applications 
that  are  based  on  terminal  emulation  are  not  suitable  for  the 
distributed  environment  (27:300). 

User  Interface  Location.  One  way  to  avoid  the  terminal  emulation 
problem  is  to  place  the  application  program,  or  at  least  the  user 
interface  portion  of  it,  as  close  to  the  end-user  as  possible.  This  can 
be  achieved  by  using  departmental  processors  and/or  networked 
workstations/PCs.  The  application  programs  can  then  use  the  network  to 
gain  access  to  data  stored  in  other  computers,  either  locally  or  at 
other  network  locations.  This  type  of  configuration  is  often  referred 
to  as  a  client-server  relationship  where  the  application  program  is  the 
client  and  the  computer  with  the  database  is  the  server.  This 
establishes  a  true  process-to-process  conmuni cat ions  link  that  is 
capable  of  making  effective  use  of  the  network's  available  bandwith. 
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Open  Systems  Computing.  The  desire  to  be  free  of  any  particular 
vendor's  computing  environment,  is  best  summed  up  in  a  quote  from  the 
developer  of  the  US  Government,  Federal  Information  Processing  Standards 
(FIPS): 

For  both  economic  and  technological  reasons,  information 
systems  users  can  no  longer  afford  the  safe  haven  provided  by 
proprietary  solutions.  Nor  do  they  seek  those  safe  solutions. 
Users  are  now  demanding  that  vendors  supply  products  that  meet 
their  requirements  for  portability  and  interoperability  of 
software  environments  and  the  applications  that  run  in  those 
environments.  (26:38) 

To  meet  this  level  of  interoperability  requires  using  vendor  independent 
standards  in  a  number  of  areas.  The  four  areas  that  are  relevant  to 
this  research  are  OSI  networking  standards.  Portable  Operating  System 
for  Computer  Environments  (POSIX),  the  X-Windows  standard,  and  the 
Structured  Query  Language  (SQL)  for  database  management  and  access. 

Open  Systems  Interconnection.  Open  Systems  Interconnection 
(OSI)  defines  the  network  standards  necessary  to  enable  vendor 
independent  internetworking  of  heterogeneous  computer  systems .  OSI  is 
discussed  further  in  Appendix  A. 

POSIX.  POSIX  is  based  on  the  AT&T  Unix  System  V,  and 
defines  standard  ways  of  obtaining  operating  system  services.  Unix  is 
the  only  computer  operating  system  that  is  capable  of  being  implemented 
on  a  wide  variety  of  hardware  system  and  thus  is  seen  as  an  important 
element  in  maintaining  vendor  independence.  Two  competing  organizations 
that  will  play  a  significant  role  in  the  future  of  Unix  are  the  Open 
System  Foundation  (OSF)  and  Unix  International  (UI).  UI  is  committed  to 
supporting  the  future  AT&T  Unix  System  V  Release  4  and  OSF  will  develop 
OSF-1  from  a  version  of  IBM's  AIX,  which  is  itself  derived  from  System  V 
Release  2.  There  has  been  a  lot  of  disagreement  between  the  various 
vendors,  but  it  now  appears  that  both  OSF  and  UI  will  develop  different 
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Unix  implementations,  although  they  both  will  be  based  on  the  POSIX 
standard  (25:141). 

Windows  Standard.  OSF  and  UI  have  also  defined  user 
interfaces  based  on  the  device  independent  X-Windows  standard  developed 
by  the  Massachusetts  Institute  of  Technology.  X-Windows  is  a  windowing 
standard  for  bit-mapped  displays  that  is  operating  system  and  network 
protocol  independent.  The  OSF  Motif  user  interface  may  have  more 
support  in  the  industry  (31:53). 

Structured  Query  Language .  SQL  has  become  the  standard  for 
operation  with  relational  database  management  systems  (DBMS).  SQL  is 
the  basis  for  IBM's  relational  databases  and  the  large  DBMS  vendors, 
like  Relational  Technology  Inc.  and  Oracle  Corporation,  have  also 
standardized  on  SQL. 

DESINE  Goals 

DESINE  is  the  outcome  of  the  1981  Defence  Computing  Infrastructure 
Working  Party  decision  to  decentralize  administrative  computing.  The 
scope  of  DESINE  was  later  expanded  to  include  all  non-embedded  computer 
systems  suitable  for  standardization.  Decentralization  is  to  be 
achieved  by  defining  technical  standards  that  would  allow  the 
decentralization  along  functional  lines  and  effective  vertical  and 
lateral  interaction  between  differing  functions  in  a  distributed 
computer  environment  (11:A-1).  The  benefits  of  the  DESINE  contract 
include: 

a.  the  contracted  availability  of  a  range  of  proven  hardware 
and  software  products  needed  to  implement  a  proven  network 
architecture,  leading  in  turn  to  improved  interoperability. 
This  range  of  products  has  been  evaluated  as  having  the 
highest  overall  cost  effectiveness  available; 

b.  savings  in  training  and  other  support  costs; 
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c .  increased  contingency  and  backup  potential ; 

d.  the  contracted  availability  of  acceptable  new  technology  and 
of  products  compatible  with  Defence  OSI  aims; 

e.  increased  Austral ian/New  Zealand  (ANZ)  industry 
participation; 

f.  a  simplified  procurement  process  for  the  supply  of 
contracted  products ;  and 

g.  availability  of  maintenance  for  10  years  after  equipment 
delivery.  (10:1) 

DESINE  and  OSI .  Defence  is  committed  to  the  adoption  of  the 
International  Standards  Organization's  (ISO),  OSI  standards  when  they 
become  commercially  available.  The  DESINE  RFT  required  a  commitment  to 
the  implementation  of  OSI  and  will  implement  solutions  based  on  the 
Australian  Government  OSI  Profile  (GOSIP)  when  it  is  made  an  Australian 
standard.  The  draft  Australian  GOSIP  Version  1.0  was  issued  in  April 
1989  and  is  based  on  the  GK  GOSIP  Version  3.0  with  changes  made  to  suit 
Australian  requirements  (12’.iv).  If  DESINE  is  implemented  using  IBX's 
SNA  there  are  some  doubts  if  compliance  with  GOSIP  will  be  possible  in 
the  near  future,  if  at  all.  Network  experts  believe  that  IBX  intends  to 
provide  gateway  services  from  SNA  to  OSI  and  both  architectures  will 
coexist.  The  use  of  gateways  causes  some  loss  of  functionality,  for 
instance  reduced  speed  and  compatibility  (28:174-175).  IBX  literature 
also  supports  the  concept  of  the  co-existence  of  SNA  and  OSI  for  some 
time  into  the  future  (1).  The  goal  architecture  will  be  designed  using 
Australian  GOSIP  network  standards.  ISDN  standards  are  not  included  in 
the  present  version  of  GOSIP,  so  where  such  standards  are  needed, 
authoritative  opinion  from  current  literature  was  used  to  assess  the 
likely  outcome  of  standardization  activity.  Future  versions  of  the 
Australian  GOSIP  will  include  a  provision  for  ISDN  (12:1-5). 
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DISCON  Specifications.  An  aspect  that  places  constraints  on  the 
architecture  design  is  the  requirement  to  interface  to  the  DISCON  packet 
switching  network  for  all  inter-base  communications.  Advice  received 
from  the  Department  of  Defence  -  Project  Development  and  Communications 
Division,  was  that  the  packet  switching  network  would  at  least  be  using 
CCITT  X.25  (1984)  standards,  and  possibly  the  1988  version  of  the 
standard  (20). 

Options  for  Using  ISDN  Technology 

Basic  Building  Block.  The  basic  building  block  of  an  ISDN  is  the 
64  kbps  unrestricted  digital  channel,  which  means  that  the  network  will 
pass  the  bit  stream  unaltered.  This  is  often  referred  to  as  a 
transparent  channel.  When  the  concept  of  ISDN  was  first  being  developed 
64  kbps  was  the  bandwith  necessary  to  pass  digitized  voice.  This 
consisted  of  an  8  kHz  sampling  rate  with  8  bits  in  each  sample.  This 
form  of  encoding  is  called  pulse  code  modulation  (PCX).  More 
sophisticated  encoding  algorithms  can  reduce  the  required  bandwith.  In 
the  early  1980s  Adaptive  Differential  PCX  (ADPCX)  was  introduced  that 
required  only  32  kbps  to  transfer  the  same  quality  of  voice  signal 
(38:189).  Today,  16  kbps  is  considered  adequate  for  speech  encoding, 
although  lower  rates  are  possible  (9:231).  The  rapid  development  is 
speech  encoding  techniques  is  an  example  of  what  the  standards 
committees  must  contend  with.  On  one  hand,  trying  to  define  something 
as  complex  as  ISDN  is  going  to  take  a  long  time,  meanwhile, 
technological  enhancements  can  change  original  assumptions.  The  whole 
reason  for  defining  the  basic  building  block  as  64  kbps  was  to  be  able 
to  pass  PCX  encoded  voice  signals.  Regardless  of  the  developments  in 
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new  voice  encoding  techniques,  the  ISDN  building  block  remains  as  64 
kbps  full-duplex  channel. 

Basic  Rate  Interface.  The  basic  rate  interface  (BRI)  consists  of 
two  independent  64  kbps  bearer  or  B  channels  and  one  16  kbps  signalling 
or  D  channel.  These  three  channels,  that  total  144  kbps,  are 
multiplexed  over  a  192  kbps  interface.  The  additional  bandwith  is 
needed  for  synchronization  purposes.  The  BRI  allows  for  a  multi-drop 
configuration  where  up  to  eight  physical  devices  can  share  the  same 
interface.  (38:283). 

Primary  Rate  Interface .  The  primary  rate  interface  (PRI) 
structure  varies  depending  on  whether  the  North  American  or  European 
standard  is  used.  The  North  American  PRI  is  based  on  the  DS-1  signal 
structure  which  is  used  on  the  T-l  transmission  service  at  1.544  Xbps . 
This  consists  of  23  B  channels  and  a  64  kbps  D  channel.  The  European 
standard  is  based  on  the  2.048  Xbps  digital  trunk  standard.  The 
European  PRI  consists  of  30  B  channels  and  a  64  kbps  D  channel  (38:290). 
The  Australian  ISDN  standards  will  be  based  on  the  European  system. 

Other  Channel  Rates .  In  addition  to  PRI  access  consisting  of  23 
or  30  B  channels,  it  is  possible  to  combine  B  channels  to  provide  higher 
data  rate  channels.  A  PRI  can  provide  multiple  384  kbps  HO  channels,  or 
all  the  B  channels  can  be  combined  giving  either  a  1.536  Xbps  Hll 
channel  (North  America)  or  a  1.920  Kbps  H12  channel  (Europe).  These 
higher  rate  channels  are  suitable  for  video  applications  or  high  speed 
data  channels  (38:189-192). 

Signalling  Channel.  Much  of  the  flexibility  of  ISDN  comes  from 
the  existence  of  the  separate  signalling  channel.  Unlike  the  B  and  H 
channels  that  are  transparent,  as  far  as  the  ISDN  is  concerned,  the  D 
channel  has  a  layered  structure  built  upon  it. 
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Link  Access  Protocol.  The  first  layer  consists  of  a  data 
link  protocol  called  Link  Access  Protocol  D  (LAPD) .  In  many  ways  LAPD 
is  similar  to  the  LAPB  used  in  X.25  Packet  Switched  Data  Network  (PSDN). 
Figure  1  shows  the  LAPD  frame  structure. 
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Figure  1.  LAPD  Frame  Structure  (38:294) 


LAPD  is  based  on  the  International  Standards  Organization  (ISO)  High- 
level  Data  Link  Control  (HDLC)  protocol.  The  flags  are  used  to  identify 
the  start  and  end  of  a  valid  frame  and  consist  of  a  special  bit  pattern, 
01111110.  All  HDLC  type  of  protocols  allow  the  transparent  transfer  of 
user  data  by  a  hardware  process  known  as  bit  stuffing  and  removal.  The 
concept  is  to  break  up  sequences  of  Is  greater  than  five  so  the  flag 
patterns  can  only  occur  where  they  should.  The  reverse  procedure  is 
then  applied  to  recover  the  correct  user  data.  The  control  field  is 
used  to  control  the  operation  of  the  data  link.  If  acknowledged 
transmissions  are  being  used,  which  is  the  normal  case,  the  control 
field  contains  frame  numbers  for  error  recovery  and  flow  control  to 
prevent  a  fast  transmitter  of  data  from  swamping  the  receiver.  The 
frame  check  sequence  (FCS)  is  a  sophisticated  check  sum,  based  on  the 
contents  of  the  frame,  which  gives  a  high  probability  of  detecting  a 
corrupt  frame.  The  field  that  is  different  from  a  normal  HDLC  frame  is 
the  address  field.  LAPD  has  to  deal  with  two  levels  of  addressing. 


First  there  can  be  multiple  user  devices  sharing  the  one  interface,  so  a 
terminal  endpoint  identifier  (TEI)  is  used  to  define  the  physical 
device.  Within  each  device  there  may  be  several  entities  using  the  LAPD 
service.  To  differentiate  between  various  entities,  a  service  access 
point  identifier  (SAPI)  is  used.  The  TEI  and  the  SAPI  uniquely  identify 
a  LAPD  entity,  and  the  corresponding  Layer  3  entity,  at  the  ISDN 
interface  (38:295-296). 

Network  Laver  Protocol.  The  main  purpose  of  LAPD  is  to  pass 
network  layer  messages  between  the  ISDN  terminal  equipment  and  the 
network.  These  network  control  messages  are  defined  in  the  Q.931  ISDN 
standard.  Q.931  messages  are  used  in  the  setup,  in-process  and 
termination  phases  of  a  call  to  provide  complete  control  of  the 
connection  (38:309).  Xore  advanced  features,  like  call  forwarding  and 
user  groups,  can  be  provided  by  the  Layer  3  messages.  Network 
management  features  are  also  implemented  by  using  Q.931.  This  gives  the 
ability  for  monitoring  network  status  and  invoking  fault  isolation  tests 
at  the  ISDN  interface  (34:6).  Q.931  messages  have  a  protocol 

discriminator  at  the  start  of  the  message  to  allow  multiple  Layer  3 
entities,  identified  by  different  SAPIs,  to  share  the  same  interface. 
This  feature  is  used  to  provide  a  low  volume  X.25  data  service,  as  well 
as  Q.931  signalling,  in  the  D  channel  (38:305). 

X.25  Packet  Switching  Service.  The  CCITT  has  defined  two  methods 
for  interfacing  to  a  X.25  PSDN  via  an  ISDN.  The  two  methods  are  defined 
in  the  X.31  standard  and  differ  in  the  packet  processing  location.  The 
first  method  simply  provides  a  circuit  switched  B  channel  from  the  ISDN 
to  the  PSDN  and  all  packet  processing  in  done  by  the  PSDN.  The  second 
method  is  to  place  a  packet  handler  in  the  ISDN  and  to  link  the  packet 
handler  to  the  PSDN  using  the  X.75  protocol,  which  is  the  standard 


method  of  interconnecting  separate  X.25  networks.  The  advantages  of 
placing  the  X.25  packet  handler  in  the  ISDN  include  reduced  delay  for 
intra-ISDN  traffic  and  the  ability  to  use  either  a  B  channel  (using 
LAPB)  or  the  D  channel  (using  LAPD)  (16:346-348). 

Multiplexing  into  the  B  Channel.  For  many  users  who  do  not 
require  the  whole  64  kbps  B  channel  bandwidth,  it  is  desirable  to 
provide  a  multiplexing  capability  to  allow  multiple  access  to  the  one  B 
channel.  The  multiplexing  functions  are  provided  by  devices  called 
terminal  adapters  (TA)  that  allow  non-ISDN  devices  to  access  the 
network.  Two  methods  have  been  standardized  to  provide  b  channel 
multiplexing,  the  original  concept  is  based  on  bit  level  multiplexing 
and  the  more  recent  concept  is  to  multiplex  Level  2  frames.  Both 
methods  rely  on  the  establishment  of  a  circuit  switched  B  channel  which 
means  that  all  multiplexed  data  from  a  channel  must  have  the  same 
destination . 

V. 110.  The  standard  for  bit  level  multiplexing  is  called 
V.110  and  allows  combinations  of  8,  16  or  32  kbps  sub-channels.  The 
steps  in  V.110  are  to  first  rate-adapt  the  input  (if  required)  to  bring 
it  up  to  the  nearest  sub-channel  capacity,  and  then  multiplex  the  sub¬ 
channels  into  the  B  channel.  The  input  data  rate  is  specified  in  the 
call  setup  message  on  the  D  channel  and  the  network  will  only  allow  a 
connection  if  the  rates  are  the  same  (38:246-251).  For  example,  a  9.6 
kbps  asynchronous  terminal  can  be  rate-adapted  to  a  16  kbps  synchronous 
sub-channel .  This  means  that  four  such  devices  could  access  the  one  B 
channel  using  a  TA. 

V.120.  The  V.120  standard  was  originated  in  the  US  and  is 
based  on  LAPD  procedures  with  flag-stuffing  used  to  fill  the  channel. 
V.120  is  more  flexible  that  V.110  in  that  it  can  allocate  variable 
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bandwidth  to  more  users  on  demand,  although  it  suffers  from  the  overhead 
of  protocol  processing  of  the  LAPD  frames.  Unlike  V.110,  V.120  can  be 
used  on  B,  HO,  Hll  or  H12  channels.  V.120  manages  the  channel  by  using 
a  13  bit  logical-link  ID  (LLID)  and  four  Q. 931-like  messages  to 
establish  connections.  If  a  separate  D  signalling  channel  is  not 
available,  for  example  in  a  pre-ISDN  implementation,  V.120  can  still  be 
implemented  (provided  LAPD  is  available)  by  using  in-band  signalling 
with  the  LLID  set  to  zero  (42:143-144). 

USAF  Local  Information  Transfer  Architecture.  The  USAF  Local 
Information  Transfer  Architecture  (LITA)  is  currently  being  prototyped 
and  evaluated  at  Xather  AFB,  CA.  The  LITA  is  based  on  ISDN  standards 
and  provides  a  base-wide  digital  network  consisting  of  multiple 
switching  nodes.  The  architecture  recommends  a  minimum  of  two  switching 
nodes,  with  more  being  required  for  larger  bases.  The  switching  nodes 
are  connected  by  high  speed,  fiber  optic  links.  Service  nodes  provide 
user  access  to  the  switching  nodes.  Individual  users  can  be  provided 
with  BRI  access,  and  users  who  spend  20  to  50  percent  of  the  time 
communicating  with  other  users  in  the  same  functional  area,  will  be 
connected  by  LANs.  LAN  interconnection  will  be  provided  by  ISDN  up  to 
the  PRI  rate  (1.544  Xbps),  with  higher  rates  being  provided  by  point-to- 
point  fiber  optic  connections. 

LITA  Management.  To  provide  the  flexibility  required  to 
meet  the  varying  user  demands,  and  to  meet  contingencies,  all  service 
nodes  will  be  connected  to  a  central  base  network  management  centre. 

This  centre  will  be  able  to  manage  bandwidth  allocation,  restore  basic 
services  in  the  event  of  network  failures,  and  provide  automatic  test 
and  full  management  facilities  (2:pp.  3-1  to  3-14). 
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Scale  of  ISDN  Implementation.  The  options  for  implementing  ISDN 
range  from  replacing  existing  leased  lines  connecting  distant  locations 
to  being  the  only  telecommunications  medium  used  for  all  voice,  video 
and  data  requirements .  The  achievement  of  the  latter  option  in  one  step 
would  be  cost  prohibitive,  although  this  might  be  a  realistic  long-term 
goal.  Also  current  applications  are  not  structured  to  take  advantage  of 
the  integration  of  voice  and  data  at  the  desktop  (18).  The  proposed 
RAAF  IS  goal  architecture  will  take  a  phased  approach  towards  adopting 
ISDN  as  the  primary  method  for  providing  connectivity. 

Future  ISDN  Developments.  There  are  two  significant  developments 
planned  for  ISDN  that  will  enhance  its  capability.  One  is  an  extension 
of  the  V.120  concept  called  frame  relay  and  the  other  is  the 
introduction  of  broadband  ISDN  (B-ISDN).  Frame  relay  and  B-ISDN  will  be 
discussed  and  an  assessment  made  of  the  likely  impact  on  the  goal 
architecture. 

Frame  Relay.  Frame  relay  is  an  enhanced  form  of  packet 
switching  that  is  based  on  LAPD  and  is  estimated  to  provide  10  times  the 
speed  of  existing  X.25  PSDN.  X.25  provides  error  detection  and 
correction  on  a  link-by-link  basis  using  the  Layer  2  protocol  and  end- 
to-end  acknowledgements  and  multiplexing  at  Layer  3.  This  means  that 
the  packet  switching  nodes  must  process  both  Layers  2  and  3.  The 
concept  of  frame  relay  is  to  combine  the  Layer  2  and  3  functions  into 
Layer  2  and  reduce  the  amount  of  processing  required  at  the  switching 
nodes.  The  processing  is  reduced  by  only  providing  a  core  set  of  Layer 
2  functions  at  the  switching  nodes,  with  any  additional  functions 
applied  on  an  as-required  basis  by  the  end  user  devices,  not  the 
network.  The  core  functions  are  those  required  to  detect  an  error  in  a 
LAPD  frame,  in  which  case  the  frame  is  simply  discarded  and  it  is  up  to 
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the  end  points  to  recover  from  the  error.  The  significant  reduction  in 
error  rates  in  ISDN*  make  this  a  reasonable  approach  to  take.  The 
ability  to  use  the  D  signalling  channel  for  call  management  also 
provides  speed  improvement  by  reducing  the  complexity  of  the  data 
transfer  phase.  The  fact  that  multiplexing  and  switching  is  done  at 
Layer  2  does  not  preclude  the  use  of  X.25  at  Layer  3.  Frame  relay 
services  will  be  defined  initially  for  rates  up  to  2  Mbps,  but  this 
could  potentially  reach  45  Kbps  (39).  The  high  speeds  available  with 
frame  relay  make  it  possible  to  send  digitized  voice  using  LAPD, 
although  this  is  likely  to  require  some  form  of  timing  adjustment  at  the 
destination  to  account  for  the  variable  delay  of  the  frames  (38:106). 
Much  interest  has  been  shown  in  frame  relay  in  the  US  and  while  the 
CCITT  standards  for  frame  relay  are  being  developed  in  the  1989-1992 
working  session,  initial  services  are  already  being  offered  by  some 
vendors  (5).  IBM  is  very  interested  in  frame  relay  because  of  the  poor 
match  between  SNA  and  X.25.  SNA  treats  the  X.25  Layer  3  virtual  circuit 
as  a  means  of  providing  connectivity,  which  is  really  a  Layer  1 
function,  and  then  proceeds  to  overlay  SNA  Layer  2  and  3  protocols  on 
top  of  this  already  reliable  service.  This  takes  up  time  and  processing 
power  (39:68).  Frame  relay  integrates  packet  switching  services  into  an 
ISDN  in  a  very  efficient  and  flexible  manner  and  seems  ideally  suited  to 
the  types  of  services  required  in  the  RAAF  IS  goal  architecture. 

B-ISDN.  After  considering  alternatives  for  providing  the 
considerable  higher  bandwidths  required  for  B-ISDN,  in  the  order  of  150 
to  600  Kbps,  the  CCITT  has  decided  on  asynchronous  transfer  mode  (ATM) 
as  the  transmission  method.  ATM  is  a  packet-switched  system,  but 
instead  of  variable  length  packets  or  frames,  a  fixed  length  frame 
format  is  used.  The  size  of  the  frame  has  not  been  decided  but  is 


likely  to  be  in  the  range  of  32  to  64  bytes.  This  allows  switching  to 
be  done  at  Layer  1  and  thus  increase  performance.  Higher  level  services 
can  be  built  on  top  of  this  basic  fixed  size  frame  switching,  for 
instance,  ATM  can  be  used  to  transport  LAPD  frames,  just  as  LAPD  frames 
can  transport  X.25  packets  (41:1549-1550).  One  of  the  main  motivations 
for  B-ISDX  has  been  for  the  distribution  of  full-bandwidth  video  to 
provide  a  service  similar  to  cable  TV  (38:344-352).  This  type  of 
service  is  likely  to  have  limited  application  in  a  military  environment 
and  considering  the  potential  of  frame  relay  and  the  early  stages  of 
development  of  ATM,  B-ISDN  is  not  considered  appropriate  for  the  goal 
architecture  in  the  foreseeable  future. 

Deriving  the  Goal  Architecture 

The  proposed  goal  architecture  at  a  base  level  consists  of  a 
centralized  computing  facility  and  distributed  departmental  or  work 
group  computers.  In  addition  to  the  computers,  operating  systems,  user 
terminal  devices  and  the  hardware  and  software  to  provide  network 
connectivity  are  required.  Figure  2  provides  the  layout  of  the  goal 
architecture  for  a  typical  base. 

Computers  and  Operating  System.  Different  size  computers  are 
required  to  meet  the  various  user  requirements  and  all  systems  should 
use  the  multi-user  Unix  operating  system.  In  the  future  it  should  be 
possible  to  specify  the  POSIX  Unix  standard  in  procurement  activity,  but 
at  the  moment  specifying  the  AT&T  Unix  System  V  Release  3  is 
reconanended.  The  reason  for  this  is  that  Release  3  is  the  only  widely 
available  Unix  standard  at  the  moment  and  the  fact  that  the  RAAF  already 
has  a  significant  investment  in  System  V  Release  2  based  systems. 
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Figure  2.  Base  Level  Goal  Architecture 
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User  Terminal  Devices.  The  traditional  character  based  terminal 
is  still  the  most  cost-effective  way  to  provide  computing  resources  to  a 
user.  Xany  IS  applications  in  the  RAAF  are  suited  for,  and  could  not 
justify  not  using,  character  terminals.  These  applications  vary  from 
transaction  processing  to  casual  OA  activities.  The  more  advanced  type 
of  applications  can  benefit  from  a  windowing  environment.  A  relatively 
new  development  called  the  X-Terminal  is  beginning  to  show  promise  in  an 
Unix  environment  (3).  The  X-Terminal  contains  a  processor  to  manage  the 
bit-mapped  display  screen,  keyboard  and  a  mouse.  The  applications  that 
produce  the  information  in  the  windows  run  on  other  processors  that  are 
connected  by  some  type  of  network.  In  effect,  a  X-Terminal  is  a  cross 
between  a  character  terminal  and  a  full-blown  X-Vifindow  workstation  with 
a  price  in  between,  but  closer  to  the  character  terminal.  X-Windows 
workstations  can  be  used  for  demanding  applications  that  can  justify  the 
additional  cost.  If  IBX  (or  compatible)  PCs  are  required,  the  Lan 
Xanager/X  product  provides  fileserver  and  distributed  application 
support  from  a  Unix  host  (23:237). 

Network  Hardware.  There  are  three  separate  components  to  the  goal 
architecture  network  structure,  the  X-Terminal/workstation/PC  to 
workgroup  Unix  processor,  the  workgroup  to  central  base  computing 
facility,  and  the  inter-base  network.  The  first  of  these  is  provided  by 
using  a  IEEE  802.3/5  LAN  and  this  component  is  independent  of  the  other 
two.  Character  terminals  would  be  directly  connected  to  the  Unix 
computer,  although  in  the  long  term,  this  connection  could  be  provided 
by  ISDN.  The  third  component  is  provided  by  DISCON  and  involves 
interfacing  to  the  X.25  network.  ISDN  frame  relay  is  proposed  for  the 
interconnection  of  the  processors  on  a  base  in  the  goal  architecture, 
but  because  frame  relay  is  not  a  viable  product  just  yet,  a  migration 
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path  is  required.  Although  the  migration  path  will  affect  hardware,  the 
decisions  are  based  more  on  software  aspects. 


Network  Software.  Because  the  802.3/5  LAN  is  as  independent 
component,  any  reliable  network  transport  service  would  suffice, 
although  it  would  be  logical  to  make  the  LAN  protocols  as  compatible  as 
possible  with  others  in  the  network.  The  provision  of  a  reliable 
transport  service  involves  Layers  2  to  4,  as  far  as  software  is 
concerned.  Because  Layer  4,  the  transport  layer,  is  an  end-to-end 
protocol,  it  is  best  to  determine  that  protocol  first. 

Transport  Protocol .  OSI  defines  five  classes  of  transport 
protocols  (TP),  that  when  matched  with  the  service  provided  by  Layer  3, 
the  network  layer,  provide  a  reliable  transport  service  to  the  Level  4 
user.  The  service  provided  by  the  network  layer  is  classified  as  either 
connection  oriented  (CO)  or  connectionless  (CL).  A  CO  service  requires 
an  exchange  of  messages  to  establish  (and  release)  the  connection  and 
then  the  acknowledged  transfer  of  data.  A  CL  service  does  not  require 
connection  establishment,  but  mealy  tries  to  deliver  data,  without 
acknowledgement,  and  with  no  guarantee  of  delivery.  The  Australian 
GOSIP  requires  using  TP4  for  CL  networks  and  at  least  TPO,  but 
preferably  TPO  and  TP2,  for  CO  networks  (12:2-1).  TPO  and  TP2  are 
discussed  below  under  transport  service  functional  requirements.  X.25 
is  a  CO  service  so,  in  order  to  be  able  to  use  the  same  TP  end-to-end, 
intra-base  conmuni cat ions  should  also  be  CO. 

Transport  Service  Functional  Requirements.  There  are  six 
functions  that  must  be  provided  by  Layers  2  to  4.  These  functions  are 
network  addressing,  multiplexing,  end-to-end  flow  control,  end-to-end 
acknowledgment,  error  detection  and  recovery,  and  segmentation  of  a 
large  message  into  more  manageable  blocks  and  reassembly  at  the 


destination  (4:143-146).  TPO  is  a  simple  protocol  that  provides 
connection  management  and  segmentation  and  reassembly.  All  other 
required  functions  are  provided  by  lower  layers.  TP2  is  similar  to  TPO 
except  that  it  can  multiplex  several  transport  sessions  onto  one  network 
connection.  This  capability  also  adds  the  requirement  to  be  able  to  do 
end-to-end  flow  control  and  acknowledgement.  TPO  and  TP2  are  not 
capable  of  recovering  from  a  malfunction  that  causes  a  network  reset. 

If  this  should  occur  then  all  associated  transport  connections  would  be 
lost . 

Frame  Relay  Based  Service.  A  frame  relay  based  service  can 
be  used  to  provide  the  required  level  of  functionality.  First  the  Q.931 
setup  message  contains  the  network  address.  If  the  full  LAPD  is 
terminated  at  the  end  user  locations,  then  multiplexing,  end-to-end  flow 
control  and  acknowledgment,  and  error  detection  and  recovery  are 
provided.  Segmentation  and  reassembly  can  be  provided  by  either  TPO  or 
TP2.  The  gateway  into  the  X.25  network  would  have  to  perform  a  protocol 
conversion  and  address  translation  from  ISDN  to  PSDN  addressing.  The 
protocol  conversion  involves  mapping  the  LAPD  frame  to  the  LAPB  frame 
and  Layer  3  packet  and  vica  versa.  A  major  objection  to  protocol 
conversion  is  its  special-purpose  nature  that  can  get  out  of  hand  if 
many  conversions  are  required,  although  in  this  case  only  one  conversion 
is  proposed  (37:463).  The  alternative  would  be  to  use  X.23  packet  layer 
protocol  (PLP)  at  Layer  3.  X.25  PLP  adds  complexity  without  any  real 

benefit.  X.25  PLP  has  an  optional  D-bit  procedure  that  can  be  used  to 
provide  end-to-end  acknowledgment,  but  as  the  Australian  GOSIP  does  not 
recommend  using  this  feature,  TP2  would  have  to  be  added  to  provide  this 
acknowledgment  (12:3A-4).  This  would  mean  that  for  a  single  transport 
connection  there  would  be  three  end-to-end  acknowledgments  occurring  at 
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Layers  2,  3  and  4.  Figure  3  shows  the  goal  architecture  network 
protocols  for  Layers  1  to  4  for  the  work  group  and  also  the  DISCON 
gateway.  Other  computer  systems  at  the  computer  centre  would  have  a 
♦  protocol  stack  the  same  as  the  work  group.  Only  ISDN  user  plane 

protocols  are  shown  and  this  is  one  of  the  advantages  of  an  ISDN  where 
the  data  transfer  protocols  are  separate  from  the  control  protocols. 
This  allows  a  more  efficient  design  for  the  data  transfer  program,  by 
only  having  to  process  data  protocol  units  and  not  data  as  well  as 
control  protocol  units.  This  improves  network  throughput  and  reduces 
the  delay  on  each  data  protocol  unit. 
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Figure  3.  Goal  Architecture  Network  Protocols  (User  Plane) 
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In  addition  to  the  ISDN  user  plane  protocols,  the  standard  ISDN  control 
plane  protocols  are  required.  These  protocols  are  depicted  in  Figure  4. 
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Migration  Protocols.  To  allow  a  smooth  introduction  of  OSI 
services  and  allow  for  the  incorporation  of  existing  systems,  a 
migration  path  is  proposed.  The  lowest  common  denominator  is  likely  to 
be  a  basic  X.25  service,  possibly  based  on  the  1980  standard,  that  does 
not  use  any  transport  protocol.  This  situation  is  not  OSI  compatible 
but  does  provide  a  reliable,  and  commonly  available,  transfer  of  data 
between  end  points  implementing  this  raw  X.25  service.  If 
communications  are  required  with  OSI  networks,  then  TPO  or  TP2  can 
optionally  be  added.  During  this  migration  period  it  would  be  nice  to  be 
able  to  insulate  the  transport  users  from  the  underlying  implementation. 
Fortunately,  Unix  System  V  Release  3  has  such  a  feature.  The  migration 
protocols  shows  X.25  (1980),  but  as  long  as  all  systems  are  using  a 
compatible  version  of  X.25,  internetworking  should  be  possible.  A 
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migration  plan  should  be  established  to  provide  full  Australian  GOSIP 
compliance.  Figure  5  shows  the  X.25  migration  protocols. 
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Figure  5.  Migration  Network  Protocols 


System  V  Transport  Laver  Interface.  The  System  V  Transport 
Layer  Interface  (TLI)  was  introduced  with  Release  3  to  provide  a 
protocol  independent  method  of  accessing  the  network  services.  TLI  is  a 
progranmatic  interface  that  sits  on  top  of  a  transport  provider,  that  is 
Layer  4.  Vendors  have  used  TLI  to  develop  OSI  applications  like  X.400 
E-Mail,  File  Transfer  and  Access  Method  (FTAM)  etc.  TLI  allows  the 
protocol  stack  to  be  changed  without  having  to  modify  application 
programs.  This  is  a  boom  to  applications  developers  who  must  support 
different  protocols  (36). 


Evaluation  of  Goal  Architecture 

Estimates  of  the  actual  network  load  were  not  available  for  use  in 
evaluating  the  proposed  architecture.  The  SWU  was  devised  to  examine 
network  performance  under  varying  loads .  The  varying  loads  were  used  as 
input  to  the  CACI  COXNET  II. 5,  Version  2.9,  simulation  program,  an 
overview  of  which  is  provided  at  Appendix  C.  The  aim  of  the  simulation 
was  to  check  the  performance  of  a  64  kbps  channel  by  varying  the  number 
of  SWUs  until  the  channel  utilization  reached  the  maximum  possible  value 
of  1 . 

Appendix  D  shows  the  input  and  output  for  the  COKXET  II. 5 
simulation  for  a  network  load  of  20  SWUs.  The  load  was  varied  from  20 
to  140  SWU,  in  increments  of  20,  and  a  summary  of  the  results  is 
contained  in  Appendix  E.  The  network  performance  can  best  be  assessed 
by  looking  at  the  simulation  results  for  the  interactive  database  query 
portion  of  the  SWU.  Figure  6  shows  the  effect  of  increased  network  load 
(SWU)  on  the  average  message  delay. 
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Figure  6.  Database  Query  Performance 


The  database  query  performance  shows  a  steadily  increasing  average 
delay  with  increasing  load.  At  about  95  SWU,  this  trend  changes  and 
there  is  a  large  increase  in  delay  for  a  correspondingly  small  increase 
in  load.  The  path  from  the  work  group  (WG)  to  the  computer  centre  (CC) 
only  reaches  0.41  utilization  at  140  SWUs,  where  the  reverse  direction 
has  reached  0.993  utilization,  or  just  about  full  capacity.  The  data 
for  the  message  from  the  CC  to  the  WG  shows  a  similar  trend  with  a 
break-point  at  about  100  SWUs .  Because  of  the  under  utilization  of  the 
WG  to  CC  path,  the  delay  for  messages  in  that  direction  showed  a  gentle 
increase  across  the  entire  range  simulated. 

The  database  query  delay  time  is  affected  by  the  message  traffic 
from  CC  to  WG,  because  they  are  both  competing  for  the  same  channel. 
Interactive  performance  could  be  improved  by  using  a  priority  scheme, 
where  interactive  sessions  would  have  a  higher  priority  over  less 
critical  activities,  like  E-Mail  delivery.  Another  method  would  be  to 
use  the  second  64  kbps  B  channel  for  message  delivery,  and  only  have 
interactive  traffic  in  the  first  B  channel.  Of  course,  the  higher 
capacity  H  channels  could  be  used  which  would  reduce  the  transmission 
time,  as  well  as  the  queuing  time. 

The  simulation  of  the  link  from  the  CC  to  a  WG  has  shown  that  if  a 
network  is  designed  so  that  only  necessary  traffic  is  placed  on  the 
network,  then  a  64  kbps  channel  can  handle  a  reasonable  amount  of 
traffic  before  queuing  delays  adversely  affect  performance. 
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V.  Discussion  of  Findings 


Assessment  of  Meeting  RAAF  IS  Development  Framework  Requirements 

The  paper  titled  "A  Development  Framework  for  RAAF  Information 
Systems"  identified  four  important  aspects  of  the  IS  goal  architecture 
(33).  They  were,  identifying  a  total  system  concept,  the  ability  to 
transfer  data  between  functional  systems,  the  protection  of  classified 
data,  and  the  support  for  deployments.  An  assessment  of  how  the 
proposed  goal  architecture  meets  these  requirements  is  provided  below. 

Unifying  Total  System  Concept.  ISDN  provides  the  unifying  total 
system  concept  by  enabling  all  base  communications  requirements  to  be 
provided  by  the  one  network  structure.  A  local  base  ISDN  distribution 
system  provides  a  flexible  network  that  can  meet  all  requirements  for 
voice,  video  and  data.  The  network  management  capability  of  the  D 
channel  provides  the  fault  detection  and  rectification  necessary  to 
adapt  to  changing  requirements  in  base  communications. 

Transfer  of  Data  Between  Systems.  Two  requirements  must  be  met  in 
order  to  exchange  meaningful  data  between  computer  systems.  First, 
common  network  protocols  must  be  used  to  enable  the  reliable  transfer  of 
data,  and  secondly,  there  must  be  an  agreed  upon  format  for  the 
exchanged  data.  The  first  requirement  is  met  by  using  the  TLI  to 
provide  a  consistent  interface  to  the  users  of  the  network  transport 
service.  This  allows  the  protocols  to  migrate  from  a  basic  X.25  service 
to  full  OSI  in  a  controlled  fashion.  The  second  requirement  is  more 
difficult  to  obtain,  as  it  requires  agreement  from  the  various  IS 
projects  on  data  formats  and  the  problems  of  data  ownership  must  be 
addressed.  The  format  problem  can  be  simplified  if  all  systems  use  the 
same  DBMS  standard,  and  with  the  strong  emphasis  on  relational  DBMS, 


that  means  using  SQL  based  products .  Because  each  DBMS  vendor  has 
provided  a  super-set  of  the  defined  SQL  standard,  integration  problems 
can  be  reduced  by  reducing  the  number  of  different  DBMS  products  used, 
with  the  ideal  being  only  using  one  of  the  leading  DBMS  vendors.  In  any 
case,  a  Data  Administration  (DA)  function,  which  is  not  the  same  as 
Database  Administration  (DBA),  should  be  established  to  define  the  scope 
and  format  of  corporate  data.  In  simple  terms,  the  DA  function  sets  the 
policy  for  the  management  of  corporate  data,  and  the  DBAs  implement  that 
policy. 

Protection  of  Classified  Data.  The  protection  of  classified 
information  is  paramount  in  a  military  environment.  The  method 
discussed  for  the  protection  of  classified  data  in  the  earlier  draft 
paper  for  the  development  of  RAAF  IS,  is  to  implement  two  completely 
separate  networks,  one  for  unclassified  users,  and  the  other  for 
classified  users.  This  concept  has  the  advantage  of  providing 
guaranteed  separation  among  different  security  domains,  but  also  creates 
several  problems.  The  first  problem  is  that  two  independent  networks 
have  to  be  designed,  implemented  and  maintained.  A  second  problem  is 
that  this  scheme  presupposes  that  the  identification  of  classified  users 
can  be  based  on  the  functional  area  concerned,  and  remains  static  over 
time.  But,  this  is  not  generally  the  case  because  aggregated  lower 
classified  data  may  have  a  higher  classification  and  the  classification 
of  certain  data  may  change  as  the  alert  status  of  a  base  changes.  For 
instance,  in  peace-time  the  quantity  of  fuel  on  a  base  may  warrant  a  low 
classification,  but  during  increased  alert  status,  this  type  of  data  may 
become  highly  classified  because  it  indicates  capability  to  continue 
with  flying  operations. 
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End-to-End  Encryption.  To  meet  the  security  requirements, 
in  a  flexible  manner,  the  proposed  solution  is  to  use  end-to-end 
encryption  over  a  switched  B  or  H  ISDN  channel.  This  would  require  the 
acquisition,  or  development,  of  encryption  devices  that  can  encrypt  the 
B  or  H  data  channel  and  leave  the  D  signalling  channel  in  the  clear. 

This  type  of  scheme  requires  a  circuit  switched  connection  and  can  not 
make  use  of  a  frame  relay  capability  because  the  LAPD  header,  which  is 
used  by  the  switching  nodes  to  make  routing  decisions,  is  also 
encrypted.  Placing  encryption  devices  at  each  end  of  the  links  to  the 
switching  nodes  would  solve  the  routing  problem,  but  would  introduce  a 
security  risk  by  mixing  unclassified  and  classified  data  in  the 
switching  nodes.  If  encryption  devices  can  operate  above  the  Data  Link 
Layer,  then  it  should  be  possible  to  pass  encrypted  data  through  a  frame 
relay  network. 

Support  for  Deployments .  An  important  requirement  for  the  goal 
architecture  is  to  provide  support  for  deployed  operations,  which  might 
be  at  another  operational  RAAF  base,  RAAF  bare-base  facility,  or 
civilian  airfield.  If  ISDN  services  can  be  provided  at  these  other 
locations,  then  it  is  a  simple  matter  to  provide  a  connection  back  to 
any  operational  base  or  headquarters.  Again,  encryption  can  be  used  to 
protect  classified  data  over  the  public,  Telecom  Australia,  ISDN. 

Telecom  Australia  ISDN  services  are  currently  available  in  the  major 
capital  cities,  with  additional  services  being  made  available  as  time 
and  money  permit.  In  the  longer  term,  ISDN  will  be  available  at  every 
location  that  the  RAAF  may  be  required  to  operate  from.  Another 
possibility,  is  to  provide  BRI  service  by  using  remote  satellite 
equipment  (22:1049). 
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Assessment  of  Meeting  DESINE  Goals 

The  goals  of  the  DESIN'E  contract  were  discussed  in  Chapter  IV  by 
describing  the  benefits  of  the  project.  The  first  five  benefits  are 
•  dependent  on  the  particular  architecture  and  will  be  discussed  below. 

Proven  Hardware.  Software  and  Network  Architecture. 
Interoperability  between  the  different  functional  areas  is  to  be 
enhanced  by  using  a  proven  hardware,  software  and  network  architecture. 
Assuming  IBM  will  implement  SNA  protocols  for  the  DESINE  contract,  there 
is  no  doubt  that  a  proven  architecture  will  result.  But,  there  are  two 
problems  with  this  approach,  both  of  which  have  been  discussed 
previously.  The  first  is  the  poor  match  of  SNA  and  X.25,  which  is 
significant  because  X.25  is  the  standard  being  used  for  the  DISCON" 
packet  switching  service.  The  second,  and  perhaps  more  important, 
problem  is  the  lack  of  a  defined  migration  path  to  meet  the  Australian 
GOSIP  requirements.  The  proposed  architecture  used  X.25  as  a  migration 
path  towards  compliance  with  Australian  GOSIP  and  will  implement  the 
frame  relay  standards  when  they  are  finalized.  This  architecture  is 
capable  of  providing  OSI  X.400  E-Mail,  File  Transfer  and  Access  Method 
(FTAM),  and  providing  for  client-server  database  operations  using  the 
AT&T  TLI.  This  provides  a  level  of  interoperability  that  enables  the 
movement  of  data  and  messages  between  different  systems.  This,  X.25 
based,  migration  path  also  allows  many  of  the  existing  computers  to  be 
integrated  into  the  architecture. 

Saving  in  Training  and  Other  Support  Costs.  The  proposed 
architecture  will  eventually  integrate  all  information  transfer  services 
on  a  base,  and  thus  reduce  the  training  and  support  costs  involved  in 
maintaining  separate  networks  for  voice,  data  and  video.  The  use  of 
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Unix  as  the  only  operating  system  will  reduce  the  training  costs 
required  for  system  developers  and  managers . 

Increased  Contingency  and  Backup  Potential.  The  proposed 
architecture  contains  a  lot  of  small,  microprocessor  based,  Unix 
systems.  This  makes  it  possible  to  store  data  at  a  remote  backup  site 
and  the  relatively  low  cost  of  the  computer  systems  makes  the  concept  of 
a  hot  backup  economically  feasible.  This  factor  may  be  important  for 
deployments  away  from  the  main  RAAF  bases . 

The  Contracted  Availability  of  New  Technology  to  Meet  GOSIP.  The 
proposed  architecture  provides  a  migration  path  to  fully  implementing 
Australian  GOSIP  standards.  ISDN  standards  will  be  added  to  GOSIP  in 
later  versions,  so  full  compliance  using  ISDN  protocols,  will  be 
possible  in  the  future. 

Increased  Australian/New  Zealand  Industry  Participation. 

Australian  and  New  Zealand  computer  vendors  are  more  likely  to  be  able 
to  produce  systems  that  are  based  on  open  systems  standards,  like  POSIX, 
than  proprietary  systems.  Local  industry  participation  could  be  further 
enhanced  by  selecting  computer  industry  standards  for  the 
microprocessor,  computer  bus  structure  etc.  This  would  give  the  local 
vendors  an  opportunity  to  design  systems  that  would  meet  the 
requirements  of  a  contract  like  DESINE. 

Assessment  of  Meeting  User's  Communications  Needs 

Without  actual  estimates  of  the  type  and  volume  of  user  network 
traffic  it  is  difficult  to  make  any  positive  statement  about  the  ability 
of  the  proposed  goal  architecture  to  meet  user's  communications  needs. 
Nevertheless,  the  simulation  results  do  provide  a  good  indication  of  the 
type  of  network  load  that  can  be  supported  by  a  64  kbps  full-duplex  ISDN 
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B  channel.  If  communications  requirements  can  be  met  by  the  ISDK  B 
channel  then  the  provisioning  of  network  services  to  users  on  a  base  is 
simplified  because  the  ISDN  BRI  can  be  provided  at  any  location  that 
currently  has  a  telephone.  This  ability  to  quickly  relocate  computer 
equipment  is  important  in  a  military  environment. 

The  point  at  which  the  average  message  delay  began  to  increase 
rapidly  was  about  95  SWU.  Analysis  of  the  results  for  80  SWU  gives  an 
indication  of  the  performance  of  the  link  in  the  more  stable  region.  At 
80  SWU  the  average  time  between  database  queries  was  about  1.3  seconds. 
The  queries  were  an  average  size  of  2,970  bytes  and  removing  the  fixed 
one  second  delay  before  a  response  and  the  transmission  time  of  about 
0.36  seconds,  leaves  an  average  queuing  delay  of  0.44  seconds  and  a 
maximum  queuing  delay  of  1.69  seconds.  In  a  real  situation  a  small  work 
group  is  unlikely  to  be  making  queries  at  a  continuous  1.3  second  rate. 
At  the  same  time  the  80  SWU  load  generates,  on  average,  a  message  of 
average  size  5,550  bytes  from  the  WG  to  CC  every  2.5  seconds,  and  a 
message  of  similar  size  every  1.5  seconds  from  the  CC  to  WG. 

To  generate  a  real  network  load  that  is  similar  to  a  load  of  80 
SWU  in  a  normal  RAAF  environment  would  require  a  reasonable  sized  work 
group  of  very  active  users.  Performance  can  be  increased  by  reducing 
the  number  of  users  in  the  same  work  group  or  by  increasing  the 
bandwidth  of  the  link  to  the  CC. 

Conclusions 

The  key  to  the  goal  architecture  is  providing  work  group  computing 
power  at  the  user  locations.  These  systems  should  take  advantage  of  the 
price/performance  advantage  of  microprocessor  based  systems,  and  to 
ensure  future  portability  and  reduced  maintenance  costs,  the  Unix 
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operating  system  should  be  used.  These  work  group  computers  are  linked 
to  a  computer  centre  where  centralized  services,  like  DBMS  and  E-Mail 
are  provided.  This  link  will  eventually  be  provided  by  the  ISDN  frame 
relay  service,  although  initially  it  will  be  provided  by  X.25. 

This  research  has  identified  an  architecture  that  meets  the 
specific  operational  requirements  of  the  RAAF.  With  correct 
distribution  of  processing  power  the  64  kbps  ISDN  B  channel  is  capable 
of  supporting  most  user  requirements  for  low  speed  data.  The  concept  of 
ISDN  is  to  eventually  integrate  all  voice,  video  and  data  services  into 
a  flexible  network  that  is  capable  of  rapid  reconfiguration  to  meet  user 
demands.  ISDN  should  be  considered  as  the  basis  of  the  RAAF  IS  goal 
architecture . 


48 


Appendix  A:  Network  Primer 


This  appendix  gives  an  overview  of  some  networking  concepts  that 
should  allow  a  non-technical  reader  to  understand  the  network  concepts 
discussed  in  this  research.  First,  some  general  network  terms  will  be 
described,  then  the  alternative  methods  of  moving,  or  switching  data 
through  a  network.  A  short  discussion  of  the  International  Standards 
Organization/  Open  Systems  Interconnection  (ISO/OSI)  model  will  allow 
the  CCITT  X.25  network  standard  to  be  introduced. 

Types  of  Networks .  A  computer  is  an  interconnected  collection  of 
autonomous  computers,  often  referred  to  as  nodes  on  the  network.  The 
goals  of  a  network  are  resource  sharing,  both  equipment  and  data, 
improved  reliability  by  having  alternative  sources,  and  cost  saving 
because  of  the  better  price/performance  ratio  of  small  computers  as 
compared  to  large  ones.  Computers  in  the  same  geographic  location, 
generally  within  a  few  miles,  can  be  interconnected  with  Local  Area 
Networks  (LAN).  Connectivity  between  widely  dispersed  computers  or  LANs 
is  provided  by  Wide  Area  Networks  (WAN).  WANs  typically  operate  at 
speeds  much  less  than  LANs  (40:2-4). 

Network  Data  Switching.  There  are  three  basic  ways  that  data  can 
be  transported  through  a  network.  They  are  by,  circuit  switching, 
message  switching,  or  packet  switching.  In  circuit  switching,  a 
dedicated  physical  circuit  is  made  between  the  two  parties  wishing  to 
communicate  and  data  is  passed  in  an  agreed  format.  Store-and-forward 
message  switching  is  another  method  of  transferring  data,  by  the  use  of 
intermediate  nodes.  A  connection  is  made  between  two  adjacent  nodes 
only  for  the  length  of  time  necessary  to  transfer  the  message.  The 
network  then  moves,  or  switches,  the  message  to  the  destination  in  a 
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series  of  hops.  A  more  refined  form  of  message  switching  is  packet 
switching.  In  packet  switching  data  is  segmented  into  small  packets  and 
the  packets  are  switched  through  the  network.  Packet  switching  networks 
can  be  used  to  implement  a  message  switching  capability  (38:65-78).  • 

Open  Systems  Interconnection  Model.  ISO  developed  a  seven  layer 
OSI  network  model  that  clearly  defined  the  functions  of  each  layer  in 
the  network.  Interfaces  between  the  layers  were  also  defined  so  as  to 
make  the  implementation  of  each  layer  as  independent  as  possible  from 
the  other  layers.  Figure  7  shows  the  seven  layers  divided  into  two 
sections.  The  first  section,  consisting  of  Layers  1  to  3,  provides  the 
network  service  to  the  transport  layer.  The  second  section,  Layers  4  to 
7,  contains  those  network  functions  that  use  the  transport  service. 


Figure  7.  OSI  Xodel  (38:389) 
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Collectively,  Layers  1  to  4  are  concerned  with  the  reliable 
transfer  of  data  through  the  network,  and  are  of  concern  to  network 
designers,  and  thus  will  be  discussed  further. 

Physical  Laver.  The  physical  layer  is  concerned  with  the 
rules  that  govern  the  transfer  of  bits  between  devices.  This  includes 
the  mechanical,  electrical,  functional  and  procedural  characteristics  of 
the  interface  (38:385). 

Data  Link  Laver.  The  data  link  layer  forces  some  form  of 
order  on  the  bit  stream,  with  the  aim  of  providing  an  error-free  link 
between  two  adjacent  nodes  (38:386). 

Network  Laver.  The  network  layer  shields  the  transport 
layer  from  the  actual  transmission  and  switching  technologies.  This 
layer  is  also  responsible  for  establishing,  maintaining,  and  terminating 
connections  across  multiple  data  links  (38:386). 

Transport  Laver.  The  function  of  the  transport  layer  is  to 
ensure  that  data  units  are  delivered  error-free,  in  sequence,  and 
without  loss  or  duplication.  The  amount  of  work  done  at  this  layer 
depends  on  the  reliability  of  the  service  provided  by  the  network  layer 
(38:387). 

X.25  Packet  Switching  Standard.  X.25  is  a  very  widely  used  packet 
switching  standard  that  was  introduced  in  1976,  and  has  been  updated  at 
four  yearly  intervals.  X.25  specifies  the  network  access  from  a  host  to 
a  packet  switched  data  network  (PSDN)  by  defining  the  protocols  for 
Layers  1  to  3.  Layer  1  specifies  X.21  or  the  more  commonly  available 
X.21  bis.  The  Layer  2  protocol  is  Link  Access  Protocol  B  (LAPB).  Layer 
3  is  where  all  the  functionality  lies,  with  the  X.25  Packet  Layer 
Protocol  (PLP).  The  X.25  PLP  can  provide  up  to  4096  virtual  circuits, 
possibly  to  different  destinations,  at  the  one  network  connection.  X.25 
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(1984)  PLP  has  been  specified  as  the  connection-oriented  (CO)  network 
protocol  for  OSI  networks.  CO  services  are  provided  by  first 
establishing  a  connection  with  the  destination,  then  transferring  the 
required  data,  and  finally  releasing  the  connection.  During  the  data 
transfer  phase,  data  packets  contain  a  virtual  circuit  number  to 
identify  the  connection.  CO  networks  are  contrasted  with  datagram  or 
connectionless  (CL)  networks  where  data  packets  are  self  contained,  that 
is  contain  the  full  destination  and  source  address  etc,  and  thus 
connection  establishment  is  not  required  (38:89-101). 
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Appendix  B:  Definition  of  Standard  Work  Unit 

The  standard  work  unit  (SHU)  is  defined  as  a  specified  amount  of 
6  network  traffic  that  is  conducted  within  a  five  minute  period.  The 

interchange  involves  three  separate  activities  between  two  nodes  on  the 
network.  These  nodes  have  been  labled  CC  for  computer  centre  and  WG  for 
workgroup.  The  details  for  the  various  transaction  types  are  given  in 
Table  1. 


Table  1. 

Standard 

Work  Unit 

Transaction  Type 

Source 

Dest 

Details 

Database  Virtual 
Call 

HG 

CC 

Each  call  consists  of  3  to 

4  queries,  20  to  30  seconds 
apart.  Query  size  is  150  to 

400  bytes  and  produces  a 
reply  of  1,000  to  4,000 
bytes  after  a  one  second 
delay. 

E-Kail  or  file 
transfer 

CC 

WG 

Transfer  two  files  or  E- 
Kail  messages  of  1,000  to 

10,000  bytes  each. 

E-Kail  or  file 
transfer 

WG 

CC 

Transfer  a  file  or  E-Kail 
message  of  1,000  to  10,000 
bytes . 

The  distributions  for  message,  query  and  response  size  is  uniform. 
The  inter-arrival  distribution  for  the  transaction  types  is  gamma.  To 
vary  the  network  traffic,  the  transaction  inter-arrival  time  was  varied. 
The  message,  response,  and  file  sizes  were  selected  to  be  indicitive  of 
a  typical  situation,  and  do  not  represent  any  defined  requirements.  A 
one  second  delay  between  a  database  query  and  the  corresponding  reply 
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was  selected  to  show  some  load  on  the  database  back-end.  This  time  does 


not  indicate  any  real  specification.  In  reality  this  parameter  is  very 
dependent  on  the  type  of  hardware,  DBMS  software  and  computer  loading. 

The  SWU  load  was  varied  from  20  to  140  in  increments  of  20.  The 
various  inter-arrival  times  are  presented  in  Table  2. 


Table  2.  Transaction  Inter-arrival  Time 


SWU 

Database  Virtual  Call/ 

E-Mail  CC  -  WG 

E-Mail  WG  -  CC  (seconds) 

(seconds) 

1 

300.0 

150.0 

20 

15.0 

7.5 

40 

7.5 

3.75 

60 

5.0 

2.5 

80 

3.75 

1.875 

100 

3.0 

1.5 

120 

2.5 

1.25 

140 

2.14 

1.071 

Appendix  C:  Overview  of  COXNET  II. 5 


COXNET  II .5  is  a  telecommunications  network  analysis  program  that 
operates  on  IBX  PC-XT,  AT,  or  PS/2  PCs,  SUN-3/4  workstations,  and  DEC 
VAX/VXS  systems ,  with  implementations  being  planned  for  other  computers . 
The  program  was  developed  by  CACI  Products  Company  of  3344  North  Torrey 
Pines  Court,  La  Jolla,  CA  92037  (Phone:  (619)  457-9681).  It  uses 
discrete  event  simulation  to  model  the  operation  of  a  network  and 
provide  performance  measurements  from  a  description  of  the  network  and 
its  routing  algorithms.  COXNET  II. 5  can  be  used  to  simulate  any  WAN 
that  uses  circuit  switching,  message  switching,  or  packet  switching. 
Packet  switching  can  be  based  on  either  virtual  circuits  or  datagrams. 

No  programming  is  required  to  use  COXNET  II. 5  and  all  parameters  are 
provided  using  data  entry  screens.  The  IBX  PC-AT  Version  2.9  of  COXNET 
II. 5  was  used  for  the  simulation. 

Network  Topology 

The  network  topology  consists  of  a  series  of  nodes  that  represent 
sources  and  destinations  for  network  traffic.  Links  are  defined  that 
connect  any  two  nodes.  Input  parameters  are  required  that  define  the 
performance  characteristics  of  the  nodes,  such  as,  number  of  packet 
switching  processors  per  node  and  the  packet  switching  time  per 
processor.  Link  failure  can  be  simulated  to  determine  the  effects  of 
network  performance. 
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Network  Traffic 


COXNET  II. 5  can  simulate  circuit  switched  calls,  data  messages  (circuit 

switched  or  packet  switched)  and  virtual  circuit  calls.  Each  traffic 

category  is  defined  by  the  source  and  destination  nodes  and  a  class  of  0 

service.  Circuit  switched  calls  have  interarrival  time  distribution, 

* 

call  holding  time  distribution  parameters,  and  an  indication  of  whether 
calls  can  be  queued.  Data  messages  require  a  message  size  distribution 
parameter.  Virtual  circuit  calls  require  additional  parameters,  for 
example,  the  messages-per-call  distribution,  the  message  interarrival 
time  distribution,  the  message  size  distribution,  the  probability  of 
getting  a  response  from  a  message,  the  response  message  size,  and  the 
delay  before  transmission  of  the  response.  COK?JET  II. 5  provides  many 
distributions  and  random  number  streams  to  cover  almost  any  required 
situation . 
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Appendix  D. 


CAC:  COKSiST  !:.5  RELEASE  2.9  "/02/I989  12:54:02 

64  kbps  fu: ’-duplex  Load  20  SWU 


NODE  :D  CODE 


NODE  NAVE 


MODE  ATT3 : SUTES 


Computer  Work  Group 
Cent . 


d: s?_ay  ccllvn  o  c 

DISP.AY  ROW  0  0 

sw:'ch:\g  times  (.vs) 

CALL  SETUP  TIME  3.  0. 

VESSAGE  SETUP  TIME  0.  0. 

V  CKT  SETUP  PKT  TIME  10.00  *0.90 

PK"  PROCESSING  TVS  1 .03  1,00 

PKT  PRCC  "V  PER  K8YrE  3.  0. 

BUFFER  SIZE  (3YTES)  65535  65535 

MSG-CUTCFF  (BYTES)  buff,  size  buff,  size 
?:<r  SWITCH  PROCESSORS  *  1 

PACKET  I z : KG  DELAY  (VS)  1.33  * .00 


3. 

*3.00 
1. 00 
0. 
65535 
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CAC!  CCMSET  : : .5  RELEASE  2.9  ’1/32/1989  ’2:54:02 

64  kbps  full -duplex  Load  20  SWU 
CIRCU;-  GROUP  ATTRIBUTES 


C : RCJ : T  GROUP  ID  CODE 

CC-WG 

WG-CC 

SOURCE  MODE  ID  CODE 

CC 

WG 

ADJACE\“  MODE  ID  CODE 

WG 

CC 

NUMBER  0=  CIRCUITS 

1 

1 

DISP.AY? 

no 

no 

rWC-WAv  OPERA" ION? 

no 

no 

CIRCUIT  SPEED  (KBPS) 

64.00 

64.00 

Cl RCUIT-SW: TCH 1 NG  ATTR 1 3UTES 

BANDWIDTH  ALLOCATION? 

no 

no 

CALL  SiG.  TIME  (MS) 

n 

w  . 

0. 

ACCESS  LEVEL 

• 

*■ 

’ANDEM  CA..S? 

no 

no 

QUEUEING  ALLOWED? 

no 

no 

CALL  GUEUE  LIMIT  : 

r.or.e 

none 

MSG  SIG.  TIME  (MS) 

0. 

w  • 

PACKET-SKI  1  TCH 1  KG  A~~R  1 BUTES 

=DX  REVERSE  CK"  GROUP 

WG-CC 

CC-WG 

PRCPAGA.  DELAY  (MS) 

0. 

0. 

MAX  BUFF.  USE  (BY-  r.o  1 

•  •  *■ 

....  .  w 

no  limit 

BUFF.  RESERVE  (BYTES) 

0 

0 

MAX  VIR".  CK“S  no  : 

i  "*  •  4» 

. . 

no  limit 

FAILURE  ATTRIBUTES 

-.:ME--C-FAIL  DISTR  unspecified 

unspecified 

MTTF  (HOURS) 

0. 

0. 

"IME-’C-REPAIR  DIS"R  unspecified 

unspecif ied 

M”R  (HOURS) 

0. 

0. 

V* 
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64  kbps  fu: ’-duplex  Load  20  SWU 
CLASS-OF-SERVICE  ATTR I  B'JTES 


C.ASS-OF-SERVICE  ID  CODE  DB 

YSG 

PR:CR:rY 

CIRCUIT-SWITCHING  ATT 

1 

RI3UTES 

1 

CAL.  RETRY  D 1 STR I B . 

unspecified 

unspecified 

AVG  RE’RY  *1  YE  (YIN 

)  3. 

0. 

BANDWIDTH  REQT  (KBPS)  0. 

0. 

CACI  COYNET  11.5  SEL 

EASE  2.9  1‘ 

1/02/1989 

12:54:02 

64  kbps  fu'.: 

1 -duplex  Load 

23  SWU 

VIRTUAL 

CALL  ATTR  1  BUT 

rES 

ORIGIN  NODE  ID  CODE 

CC 

WG 

WG 

DES".  NODE  ID  CODE 

WG 

CC 

CC 

C-ASS-OF- SVC  ID  CODE 

YSG 

DB 

YSG 

WINDOW  SIZE 

0 

4 

ft 

<J 

RESPONSE  PROBABILITY 

ft 

w  • 

1.00 

0. 

RESPONSE  DELAY  (SEC) 
CA..  IN“ERARR 1 VA_  “IY 

0. 

5  (SEC) 

*.00 

ft 

PRC3.  DISTRIBUTION 

gamma 

gamma 

gamma 

PARAYE’ER  1 

7.50 

15.33 

4  C  ftft 
.  J  «  w  w 

3ARAY E'ER  2 

1.53 

*.53 

1.53 

?ARAYETER  3 

3. 

ft 

w  . 

0. 

PARAYE’ER  4 

C. 

3. 

ft 
>J  . 

$’REAV 

4 

*. 

• 

NC.  C:  YSGS  PER  CALL 

PRC5 .  D 1 S“R 1 1  ON 

constant 

ur  orrr 

constant 

PARAYE’ER  ‘ 

-  ft* 

.  •  'J'J 

3.00 

1.00 

PARAYE’ER  2 

ft 
«/  • 

4.33 

0. 

S’REAY 

YSG  IN’ERARRIVA.  TYE 

(SEC) 

ft 

3RC3.  DISTRIBUTION 

uniform 

uniform 

uniform 

PARAYE’ER  ; 

*  .03 

23.00 

1.00 

PARAYE’ER  2 

2.00 

30.00 

2.00 

PARAMETER  3 

0. 

0. 

0. 

PARAYETER  4 

0. 

0. 

0. 

STREAY 

• 

• 

* 

YSG  SIZE  (3YTES) 

PRC3.  DISTRIBUTION 

uni  fonn 

uniform 

uniform 

PARAYETER  1 

1003.00 

153.00 

1030.30 

PARAYETER  2 

10000.00 

400.00 

’0003.00 

S’REAY 

2 

2 

2 

RESPONSE  SIZE  (3YTES) 

PROB .  DISTRIBUTION 

unspecified 

uniform  unspecified 

3ARAYE’ER  1 

0. 

1000.00 

0. 

PARAYE’ER  2 

ft 

w  « 

4333.33 

0. 

S’REAY 

0 

4 

0 
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64  kbps  full-duplex  Load  20  SWU 

CIRC'.:?- SWITCHING  OPERA”  1  OS 

Cal:  Preemption  EnabTed?  No 

Ca'l  Routing  Strategy  Undefined 

3 ACXET-SW iTCHING  OPERATION 

Message  Traf f i c  Switching  Packet-Switched 

Information  Bytes  per  Packet  251 

Overhead  3ytes  per  Packet  6 

Acknowledgement  Packet  Size  6 

Link  Level  3ytes  Per  Packet  8 

Control  Packet  Priority  0  (0  defau’ts  to  highest  priority) 

Acknowledge  End  of  Message  No 

Retransmit  Interval  500  millisec 

Routing  Update  Interval  10000  millisec 

3acket  Routing  St-ategy  User-Defined  Node-by-Node  Routing  Tables 

Alternate  Routing  Rule  Maximum  Excess  Transmission  Capacity 

”raf f : c  Measure  "ype  Undefined 

Max  Distance  Crange  Threshold  0  millisec 

Distance  Change  Threshold  Reduction.  0  millisec 

Max  Flooded  Packet  Life  0.  sec 

Virtua’  Ca’l  Retry  Interval  60.00  sec 

Max  Retransmit  Attempts  0 

Call  Reo.est  Packet  Size  (3ytes)  0 

Ca'l  Connect  Packet  Size  (Bytes)  0 

Virtual  Call  Flow  Control  Strategy  Sliding  Window 
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64  kbps  full-duplex  Load  20  SWU 
NODE- 3 Y- NODE  ROUTING  TABLES  FOR  PACKE’S 
WITH  CLASS  OF  SERVICE  D3 
CIRCUIT  GROUP  ID  CODES  FOR  ROUTING  CHOICES 


ROUTING  NODE:  CC 
DEST.  NODE:  WG 

CC-WG 

ROUTING  NODE:  WG 
DEST.  NODE:  CC 

WG-CC 

4 
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64  kbps  full-duplex  Load  20  SWU 
N0DE-3Y-N0DE  ROUTING  “A3LES  "OR  PACKETS 
«  WITH  CLASS  Or  SERVICE  MSG 

CIRCUIT  GROUP  ID  CODES  FOR  ROUT i NG  CHOICES 

ROUT! KG  NODE:  CC 
DES".  NODE:  WG  CC-WG 

ROU" I KG  NODE:  WG 
DES".  NODE:  CC  WG-CC 
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64  kbps  *u:’-du?;ex  Load  20  SWU 

CIRCUIT  GROUP  PERFORMANCE 
FOR 

PACKEVSW ITCHED  TRAFFIC 
FROM  0.  "C  5.  MINUTES 


CIRC.I"  GROUP  ID  CODE 

CC-WG 

WC-CC 

SOURCE  NCDE 

Computer 
Cert . 

Work  Group 

AD.ACEIT  NODE 

Work  Group 

Computer 

Cert. 

CALL  SE'UP  DIRECTION 

• 

1 

NUM3ER  Or  CIRCUITS 

# 

SUSY  CIRCUITS  (AL.  "RAS 

r!C) 

AVERAGE 

.15 

.08 

S'ANDARD  DEVI  A" ION 

.35 

.27 

MAXIMUM 

1.00 

1.00 

CIRCUI"  GROUP  UTIL  % 

14.69 

7.88 

NO.  OF  PACKETS  TRANSMIT 

TED 

FROM  SOURCE  NODE 

2092 

2092 

3UFFER  USE  (3Y"ES) 

AVERAGE 

79.02 

36.63 

STANDARD  DEVIATION 

186.87 

122.80 

MAXIMUM 

1220.00 

824.00 

?ACKET  QUEUE  TIME  (MS) 

AVERAGE 

3.05 

.14 

S"ANDARD  DEVIATION 

8.96 

1.88 

MAXIMUM 

60.50 

32.12 
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NODE 


BUFFER  USE  (BYTE 
AVERAGE 

STANDARD  DEV! A 
MAX  i  MUM 

PACKETS  PROCESSE 
RACKETS  BLOCKED 

PST  SWITCH  WA:r 
AVERAGE 
S'ANDARD  DEV J 
MAX ’.SUM 

processor  ut: l : : 

3RCCESSCRS  ?E: 
AVG  BUSY  PROCi 

ut:.:za":on  * 
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64  kbps  full-duplex  Load  20  SWU 


PACKET  SWITCHING 
NODE  UTILIZATION  STATISTICS 
FROM  0.  TO  5.  MINUTES 


Computer  Work  Group 
Cent. 


S) 


79.02 

36.63 

'ION 

186.8: 

122.80 

1220.00 

824.00 

D 

4184 

4184 

0 

0 

TIME  (MS) 

.0’ 

.0’ 

iT ;  ON 

.25 

.18 

7.43 

7.25 

’A"  ON 

1  NODE 

1 

1 

[SSORS 

.02 

.02 

1.62 

’.62 
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10 

64  kbps  ful 

’-duplex  Load  20  SWU 

MESSAGE 

DELAY  STA' 

risTics 

FROM  0. 

TO  5.C 

!  MiNUTES 

MSGS 

AVG 

MESSAGE  DELAY 

AVG 

MSGS  SEN'  AND 

SIZE  IN 

(SECONDS) 

TOTAL 

DELAY 

OR :  6 

IN  DES“. 

COS 

BLOCKED  RECEIVED 

BYTES  AVERAGE  STD  DEV  MAXIMUM 

PACKETS 

(MS) 

CC 

WG 

MSG 

0  33 

5475.9 

.93  .47 

2.00 

735 

578 

WG 

CC 

D3 

0  58 

2737.9 

1.49  .20 

2.11 

693 

224 

WG 

CC 

MSG 

0  25 

5775.8 

.90  .40 

1.47 

588 

534 

NETWORK  rO‘A_: 

5 

0  116 

4:71.6 

1.20  .44 

2.11 

2016 

443 

NETWORK  THROUGHPUT 

12.9  KILOS! 

TS  PER  SECOND 
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64  kbps  full-duplex  Load  20  SWL' 


VIRTUAL  CIRCUIT  CALL  STATIST  ICS 
FROM  0.  "0  5.0  Y:\UTES 

(ALL  TIMES  IN  SECONDS) 


CALL 

ORIGIN 

CALL 

DEST. 

COS 

CALLS 

■TRIED 

CALLS 

3LOCKED 

CALLS 

RE¬ 

ROUTED 

SETUP  DEI 
AVG  STD 

.AY 

MAX 

CALLS 

ENDED 

AVG 

CALL 

LENGTH 

CC 

WG 

MSG 

33 

r\ 

V 

0 

.03 

.00 

.04 

33 

1 

WG 

CC 

D3 

18 

0 

0 

.03 

.01 

.05 

15 
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WG 

CC 

MSG 

25 

0 

0 

.02 

.00 

.03 

25 

63 


Appendix  E.  Simulation  Results  -  Snmmar 


The  results  of  the  COMNET  II. 5  simulation  for  a  64  kbps  full- 
duplex  circuit  from  the  Work  Group  (WG)  to  the  Computer  Centre  (CC) ,  for  • 

various  load  factors,  are  shown  in  Table  3. 


Table  3.  Sunmary  of  Simulation  Results 


Load 

Link  Utilization 

Traffic  Type 

Message 

Delay  (sec) 

(SWU) 

CC-WG 

WG-CC 

Average 

Maximum 

Msg  CC-WG 

0.93 

2.00 

20 

0.147 

0.788 

DB  Query 

1.49 

2.11 

Msg  WG-CC 

0.90 

1.47 

Msg  CC-WG 

0.97 

2.47 

40 

0.294 

0.142 

DB  Query 

1.56 

2.50 

Msg  WG-CC 

0.92 

1.89 

Msg  CC-WG 

1.20 

4.53 

60 

0.446 

0.218 

DB  Query 

1.67 

2.91 

- 

Msg  WG-CC 

1.05 

2.51 

Msg  CC-WG 

1.43 

4.75 

80 

0.608 

0.296 

DB  Query 

1.80 

3.05 

Msg  WG-CC 

1.18 

2.68 

Msg  CC-WG 

2.01 

6.75 

100 

0.767 

0.347 

DB  Query 

2.06 

4.53 

Msg  WG-CC 

1.23 

3.17 

Msg  CC-WG 

8.58 

43.08 

120 

0.912 

0.417 

DB  Query 

6.11 

19.41 

Msg  WG-CC 

1.51 

4.97 

Msg  CC-WG 

25.41 

95.71 

140 

0.993 

0.410 

DB  Query 

18.97 

70.08 

Msg  WG-CC 

1.60 

3.71 

Notes*.  1.  Message  delay  includes  queuing  and  transmission  time. 

The  database  query  also  includes  a  one  second  delay  before 
the  response  is  actioned. 


2.  The  DB  Query  is  from  WG  to  CC,  but  the  reply  message, 
which  is  larger  than  the  query  message,  is  from  CC  to  WG. 
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The  purpose  of  this  study  was  to  define  an  information 
systems  goal  architecture  for  the  Royal  Australian  Air  Force 
that  uses  Integrated  Services  Digital  Network  (ISDN)  as  the 
basic  network  structure.  To  do  this  required  gathering 
information  from  previous  studies  on  architecture 
requirements  and  present  related  projects.  Important 
requirements  were  identified  as  the  ability  to  exchange  data 
between  the  various  systems,  the  requirement  to  protect 
classified  data  and  the  requirement  to  support  deployed  RAAF 
operations . 

An  important  Australian  Defence  project  is  the  Defence 
EDP  Systems  Integrated  Network  Environment  (DESINE)  that  is 
intended  to  achieve  interoperability  among  the  various 
information  systems.  DESINE  details  are  not  firm,  but  early 
indications  are  that  proprietary  IBM  network  protocols  will 
be  used  with  a  strong  emphasis  on  mainframe  computing.  This 
concept  is  contrary  to  the  currer*-  industry  trends  where  the 
use  of  smaller  microcomputer  bas<_u  systems  that  use  open 
systems  architectures  is  advocated.  The  architecture 
presented  in  this  report  is  offered  as  an  alternative  to 
DESINE. 

Analysis  of  the  options  for  using  ISDN  technology 
indicated  that  the  concept  of  frame  relay  is  ideally  suited 
to  the  RAAF  requirements.  Frame  relay  is  a  form  of  packet 
switching,  within  an  ISDN,  where  high  throughput  and  low 
delay  are  achieved  by  reducing  the  processing  required  per 
packet.  A  migration  path  using  conventional  X.25  packet 
switching  is  proposed. 

The  proposed  architecture  distributes  processing  power 
to  user  locations  to  reduce  the  network  traffic.  This  setup 
was  simulated  using  the  CACI  COMNET  II. 5  program  and  used  a 
surrogate  load  measure  based  on  a  standard  work  unit.  This 
was  necessary  because  of  the  unavailability  of  projected 
network  load  data.  The  results  indicated  that  with 
distributed  processing  ISDN  can  meet  all  the  requirements  of 
the  RAAF  goal  architecture. 


